GTK 4.0
It is impossible to summarize 4 years of development in a single post. We’ve written detailed articles about many of the new things in this release over the past year: Data transfers, Event controllers, Layout managers, Render nodes, Media playback, Scalable lists, Shaders, Accessibility." GTK 2 has reached the end of its life.
Posted Dec 16, 2020 22:58 UTC (Wed)
by fman (subscriber, #121579)
[Link] (40 responses)
Posted Dec 16, 2020 23:23 UTC (Wed)
by flussence (guest, #85566)
[Link] (15 responses)
Posted Dec 17, 2020 0:36 UTC (Thu)
by compenguy (guest, #25359)
[Link] (14 responses)
Source? That claim seems dubious in light of the efforts to not only keep GTK portable to Windows and macOS, but also continue to do compatibility and performance work for those platforms.
Not saying it has the polish of QT, but QT has its rough edges and limitations as well. The C++ API has made QT rather painful to bind from other languages. Take a look at Rust and Swift for good examples of this. Meanwhile, GTK has top-notch language bindings for both languages. Not suggesting that makes up for inferior polish and platform support compared to QT, but it's certainly subject to individual needs and priorities.
Posted Dec 17, 2020 2:33 UTC (Thu)
by flussence (guest, #85566)
[Link] (4 responses)
The whole fiasco over how CSD was mishandled is a good read. Look up why the oxygen-gtk3 theme developer burned out for a fun horror story, and further in that vein there's https://stopthemingmy.app - an entire logo-and-website to patronisingly chastise Linux users for having the audacity to think they deserve more control than Apple gives them. Or the unsettlingly possessive behaviour when gedit tried to distance itself from the project earlier this year.
You're talking past me about “rough edges” and “polish” while completely missing the point. This is about bureaucratic nastiness and the owners' tendency to fight tooth-and-nail against any attempt to improve the software by or for Outsiders, their obstinate refusal to even admit that their product can be anything less than perfect. This toxicity is what GTK has become *known* for, and it's why nobody wants to build new software in it any more - the mere fact people are choosing to go through the pain of writing non-native Qt, choosing to port major software in GTK2 to anything but GTK3 (in some cases *re-adding GTK2*), is sending a loud and clear signal that falls on deaf ears.
Posted Dec 17, 2020 6:03 UTC (Thu)
by joshl (guest, #91369)
[Link] (1 responses)
In a wall of large sweeping statements, this one is interesting because it's immediately identifiable as misinformation and bunkum by following the link.
I go to the website and there's a large yellow banner telling me it's not aimed at "tinkerers playing with their own setup". I scroll down and there's bold text stating that if I want to theme my own system "that’s fine with us" with a polite warning that I shouldn't report my theme bugs upstream.
It's also curious that it's a website endorsed by people who are currently developing non-GNOME GTK apps, which apparently "nobody" wants to do.
Posted Dec 31, 2020 14:29 UTC (Thu)
by flussence (guest, #85566)
[Link]
If it's aimed at distros - and not community sites like gnome-look.org - where are the distro bugs filed by these app developers, and why aren't they linked to from the page as examples?
Posted Dec 17, 2020 10:59 UTC (Thu)
by pwithnall (guest, #97459)
[Link] (1 responses)
Posted Jan 6, 2021 19:40 UTC (Wed)
by efitton (guest, #93063)
[Link]
I mean it is the same people with the same attitudes and the same messages isn't it? I am a very external observer but my default that serves well is that you generally get the same behavior from the same group of people even ten years later. I haven't noticed any public facing change, but again, very external observer. Anyhow, it looks like the same group of people: https://blog.gtk.org/2020/12/17/who-wrote-gtk4/ and it looks primarily like GNOME a project with all that comes with that for good and for ill.
Posted Dec 17, 2020 18:45 UTC (Thu)
by ceplm (subscriber, #41334)
[Link] (4 responses)
Very painful experience of anybody who wanted to develop third-party app for Gnome. In the end the lesson you learn, you should develop for the Open Web only (https://www.tbray.org/ongoing/When/200x/2003/07/12/WebsTh...).
Posted Dec 20, 2020 13:00 UTC (Sun)
by scientes (guest, #83068)
[Link] (3 responses)
Posted Dec 21, 2020 1:07 UTC (Mon)
by MrWim (subscriber, #47432)
[Link] (2 responses)
That's not to say that there haven't been changes, but backwards compatibility means you only need to make modifications to take advantage of these new capabilities, rather than changes just to keep providing the same experience.
Posted Dec 21, 2020 7:16 UTC (Mon)
by dvdeug (guest, #10998)
[Link] (1 responses)
Posted Jan 2, 2021 15:55 UTC (Sat)
by ryzokuken (guest, #115983)
[Link]
Posted Dec 18, 2020 11:18 UTC (Fri)
by scientes (guest, #83068)
[Link] (2 responses)
GTK is not C, but gobject, which is basically the Vala language. You can see what a pain this is with the attempts to bind GTK to go and other garbage-collected languages.
Posted Dec 18, 2020 19:33 UTC (Fri)
by swilmet (subscriber, #98424)
[Link]
It's one of the reasons why the Xamarin Studio (MonoDevelop) developers wrote their own text widget in C#, and gave up GtkTextView (also, and mainly, because GtkTextView sucks, although they could have contributed to GTK to improve it, but C/GObject is not their favorite hobby).
Posted Jan 8, 2021 12:45 UTC (Fri)
by bengen (guest, #14957)
[Link]
Go and anything non-Go do not mix particularly well and the Go community's answer is "CGo is not Go", with the implied notion that we'd all be better off just reimplementing our C and C++ libraries in Go. Sure, Go's foreign function interface support can be used for easy things and there's even some documentation, but as soon as you want to do something nontrivial, possibly with callbacks into Go from C, your life gets interesting, and not in a good way. Once you are done fighting the garbage collector and the magic protecting it, the fun shifts to a build system that does not handle non-trivial cases such as (cross-compiling or figuring out custom search paths for headers and libraries) particularly well. You end up adding build scripts or Makefiles or lengthy instructions. If you expect others to use your Go library of C bindings (i.e. build it from source), explaining the non-standard build system or instructions then becomes a major source of entertainment.
Very little of this has anything to do with the Go runtime having a garbage collector.
Posted Dec 17, 2020 0:48 UTC (Thu)
by atnot (subscriber, #124910)
[Link] (5 responses)
Posted Dec 17, 2020 10:06 UTC (Thu)
by mchehab (subscriber, #41156)
[Link] (2 responses)
I did a port of Camorama from Gtk3 to Gtk3 two years ago, and I tried to keep it ready for Gtk4.
Camorama works by creating a GtkDrawingArea, mapping a callback that would allow filling the pixbuf area from the data retrieved from the camera. It turns that they dropped support for gdk_cairo_surface_create_from_pixbuf(). The git log is short, and just says that "it's unused", without providing any glue about how to replace it:
https://gitlab.gnome.org/GNOME/gtk/commit/7ef8696a7dc2c7a...
I remember I tried hard on that time (Gtk 3.94) to see a replacement for that. I found none. The migration instructions at:
https://developer.gnome.org/gtk4/stable/gtk-migrating-3-t...
Also doesn't help.
Posted Dec 17, 2020 11:56 UTC (Thu)
by alexl (subscriber, #19068)
[Link] (1 responses)
Of course, with Gtk 4 you ideally don't want to use cairo to draw at all as it is really the old "fallback" software rendering codepath.
The modern way to draw is to implement snapshot and create render nodes which will avoid any cairo work and just do OpenGL rendering.
However snapshot is kind of lowlevel. Its used if you want to do some custom specialized rendering. If you just want to render an image in your UI, just put the pixbuf in a in a GtkPicture subwindow. One of the nice advantages of Gtk4 is that everything, even sub-parts of widgets are just widgets. You very rarely have to have a custom drawing function that draws multiple things.
Posted Dec 17, 2020 12:05 UTC (Thu)
by alexl (subscriber, #19068)
[Link]
Posted Dec 18, 2020 14:33 UTC (Fri)
by Vipketsh (guest, #134480)
[Link] (1 responses)
I have to wonder why library authors in general don't or can't make their users into at least drive-by-developers of the library ? After all the users of the library are, by definition, also developers. If they could somehow do this then all this "very minimal porting" wouldn't need to be repeated by each user but could instead be pooled into the central library and everyone would benefit. Synergy and all that.
Posted Dec 18, 2020 20:05 UTC (Fri)
by swilmet (subscriber, #98424)
[Link]
As a personal story, after two-three years of developing a GTK LaTeX editor (during my spare time), I started to contribute to the GtkSourceView library. And in a short period of time my focus had completely switched to GtkSourceView, not the LaTeX editor anymore (because lack of time of course).
As a single individual, you cannot at the same time develop a whole application with a lot of features, *and* develop all the libraries that you use. Except if you have a lot of funding or a thriving community of contributors.
Again, to continue my personal story, nowadays I would love to write a new text widget, or to significantly improve GtkTextView. But I know that if I do that, it would become my main project for the foreseeable future, and I don't really have the funding for that.
Posted Dec 17, 2020 1:39 UTC (Thu)
by Xenophon (guest, #143699)
[Link]
Posted Dec 17, 2020 1:41 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (16 responses)
$ apt-cache rdepends libgtk2.0-0 | wc -l
Posted Dec 17, 2020 2:12 UTC (Thu)
by ebassi (subscriber, #54855)
[Link] (15 responses)
Posted Dec 17, 2020 3:11 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (13 responses)
https://bugs.debian.org/947713
The GTK1 transition also saw the loss of some things, the one that I remember was the GTK interface for nethack, which still hasn't recovered a GTK interface of any era.
Posted Dec 17, 2020 3:18 UTC (Thu)
by ebassi (subscriber, #54855)
[Link] (5 responses)
Posted Dec 17, 2020 3:31 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (4 responses)
Posted Dec 17, 2020 9:25 UTC (Thu)
by smcv (subscriber, #53363)
[Link]
It's also entirely possible to build Flatpak-style runtimes from Debian packages: https://salsa.debian.org/smcv/flatdeb can do this, and is used to build the Debian-10-based Steam Runtime v2 (which is not currently distributed as a Flatpak runtime itself, but is "the right shape" to be used as one). GTK 2 is available in Debian 10 and will be in Debian 11. I don't currently have enough bandwidth to be trying to build production-quality Debian runtimes alongside my other responsibilities, or to set up, sysadmin and fund a suitable hosting platform (CDN?) for distributing them, but someone could.
Posted Dec 17, 2020 14:16 UTC (Thu)
by ebassi (subscriber, #54855)
[Link] (2 responses)
Why would it matter? You can bundle the latest GTK2 release and build it alongside your GTK2 application. I mean: that's the entire point of Flatpak.
Posted Dec 18, 2020 6:50 UTC (Fri)
by epa (subscriber, #39769)
[Link] (1 responses)
Posted Dec 18, 2020 12:23 UTC (Fri)
by smcv (subscriber, #53363)
[Link]
GTK 2 reaching end of life means that the GTK developers are no longer willing to take responsibility for it. If you *are* willing to take responsibility for it, or at least for the subset that's used in your application, then nobody is stopping you from doing so. (Indeed, the license is irrevocable, so nobody *can* stop you.)
> If [...] there is no reason not to keep shipping the library, then you may equally well ship it as an rpm or deb package
As a downstream maintainer, I'm not exactly enthusiastic about taking responsibility for GTK 2 longer than the upstream developers do, for approximately the same reasons they have announced its EOL: every hour I spend on maintaining GTK 2 is an hour I'm not spending on something more widely beneficial, or more rewarding.
Debian will continue to ship GTK 2 as a .deb for a while, but eventually we too will be unable or unwilling to take responsibility for it. If you want to ship a third-party .deb outside Debian, or bundle it in a Flatpak app, it's up to you to maintain that in a way you are happy with (it seems to me that bundling it in a Flatpak app would be a better way to make it clear what uses you are and aren't taking responsibility for, but how you use your time and effort is not up to me).
Posted Dec 17, 2020 7:25 UTC (Thu)
by epa (subscriber, #39769)
[Link]
Posted Dec 17, 2020 9:45 UTC (Thu)
by smcv (subscriber, #53363)
[Link] (5 responses)
The original bug report that you linked says "There are currently no concrete plans to remove GTK 2 from Debian, but I'm sure it will become necessary one day", and the subsequent mass-bug-filing template said "perhaps removing GTK 2 from Debian will never be feasible". I wouldn't call that a plan to remove GTK 2 from Debian 12, unless someone else has that plan and hasn't told me.
I would *like* to remove GTK 2 from Debian eventually, but the causality is the other way around: instead of "we want to remove GTK 2, and therefore the apps must switch or be removed", it's more like "if the apps switch or are removed, then we can remove GTK 2".
The mass bug filing seems to have had the desired effect in the sense that packages that *can use* GTK 2, but don't *need* GTK 2, have been taking the hint and disabling it (either by porting to GTK 3, or by disabling more minor features that need GTK 2 in an otherwise GTK 3 or non-GTK package).
Some maintainers have been taking the initiative to remove their packages that require GTK 2 from Debian. If the only reason is "there's a bug report pointing out that GTK 2 is deprecated", then I don't think that's necessary or desirable, but if the reasoning is "its use of GTK 2 is a symptom of being generally unmaintained", then that's no bad thing.
You might notice that I'm in the Uploaders for gmpc, which is a GTK 2 music player (mpd client). I regularly use it, and if it gets removed from Debian, it's more likely to be because it was written for old Vala compilers and depends on the rather obscure gob2 than because it uses GTK 2.
Posted Dec 17, 2020 20:59 UTC (Thu)
by mattheww (guest, #108205)
[Link] (4 responses)
Does Debian consider that GTK 2 is in the archive solely in order to support other Debian-packaged applications, or is also there so Debian's users can run their own programs which might have been written against GTK 2?
That is, if the day comes when the archive contains nothing that depends on GTK 2, will the maintainers automatically think "great, we can remove it now", or would they try to find out whether there are users who still want it for its own sake?
(I ask because I saw no sign of the latter when GTK 1 was removed.)
Posted Dec 18, 2020 1:41 UTC (Fri)
by pabs (subscriber, #43278)
[Link] (2 responses)
OTOH, sometimes we get old stuff reintroduced because external things use them, for example src:libudev0-shim was recently added reintroducing libudev0 as a compat shim for libudev1.
https://github.com/archlinux/libudev0-shim
Posted Dec 18, 2020 10:27 UTC (Fri)
by mattheww (guest, #108205)
[Link] (1 responses)
But when they're looking at a piece of software which historically did
Posted Dec 19, 2020 1:31 UTC (Sat)
by pabs (subscriber, #43278)
[Link]
I definitely agree with you that Debian has a blind spot around user feedback. Apart from popcon, we don't know how important each package is to our user-base, we don't have telemetry to automatically hear about common issues and we don't have a way to pro-actively reach all users (not just those on the mailing lists) to ask them to test issues/fixes etc, we can only react to bug reports, support requests etc.
Posted Dec 18, 2020 12:10 UTC (Fri)
by smcv (subscriber, #53363)
[Link]
A bit of both. If you're developing your own programs written against GTK 2, then when it eventually gets dropped from the archive, you're well-placed to pick up responsibility from its Debian maintainers and compile your own copy of GTK 2 alongside your programs, if that's what you need. We provide you with full source code, both for the library itself and the packaging, and even if its upstream developer no longer does; so if it has bugs that are a showstopper for your particular use, then you have the option of fixing them, even if the fix is an incompatible change and you end up maintaining a fork to go with your programs.
We can't maintain superseded libraries or other runtime environments forever with a finite number of developers, and I don't think we should pretend that we can. It seems better to have a clear signal that we are no longer taking responsibility for a particular library, giving people who depend on it a chance to either pick up responsibility for having their own version, or move away from it.
There's nothing particularly special about GTK here: as a distribution, we've done this in the past for GTK older than 2, Qt older than 5, Python 2 older than 2.7, Python 3 older than 3.9, Perl older than 5.32, Ruby older than 2.7, GStreamer older than 1.0, and many more.
In practice, an old .deb from an old Debian release will often install and work acceptably on a newer release (at your own risk, no support implied), so continuing to use an unsupported library doesn't *necessarily* mean compiling your own - but if you want bugs fixed, or if you want to rebuild against newer dependency ABIs, at some point that becomes your responsibility rather than the distribution's. Anything else is just not sustainable.
Posted Dec 20, 2020 8:53 UTC (Sun)
by ms_43 (subscriber, #99293)
[Link]
This is a very short list of packages, and gtk2 and motif are the only GUI toolkits in it.
For RHEL 8, gtk2 moved to Compatibility level 2, and notably there are no GUI toolkits in level 1 any more, while level 2 has gtk2, gtk3, motif, libXaw, qt5-qt5base.
So at a minimum Red Hat has promised to support gtk2 until RHEL9 EOL for paying customers.
[0] Compatibility level 1: APIs and ABIs are stable across three major releases (starting with RHEL 7)
[1] Compatibility level 2: APIs and ABIs are stable within one major release
Posted Dec 17, 2020 2:02 UTC (Thu)
by pabs (subscriber, #43278)
[Link]
Posted Dec 17, 2020 12:03 UTC (Thu)
by sam.thursfield (subscriber, #94496)
[Link]
I think this is an interesting time to be a desktop toolkit. For simple apps it's now practical to use HTML5 for the UI -- either with Electron / nw.js, or rolling your own thing with a WebKitWebView or similar -- and this has the advantage that you can serve the same UI as a browser app.
At the same time, GTK 4.0 has added a bunch of nice things for making simple apps, such as the new lazy listmodel, and combined with Flatpak and Flathub the story for native app developers is better than ever.
It'll be interesting to see how things play out. Either way it will hopefully lead to more great apps available for Linux desktop OSes.
Posted Dec 18, 2020 8:16 UTC (Fri)
by swilmet (subscriber, #98424)
[Link] (1 responses)
Now, almost 10 years later, it's an order of magnitude more code that I develop and maintain. Composed of libraries plus several applications that use GTK 3. And, after reading the GTK 4 porting guide, I'm definitely not excited. Over the years, being a GNOME developer has made me suffer from too much stress, maybe I should have given up years ago. I now regret not investing time learning C++ and Qt.
The GTK documentation is still incomplete. The GTK 4 porting guide is not exhaustive. And some new classes lack proper documentation.
The language bindings! Ha! It's both a benediction and a curse. In GNOME, many many software components are being rewritten in other languages. There has been the C# wave, the Vala wave, a JavaScript wave, now the Rust wave. When a module is "semi-finished", it gets rewritten in another language, or gets replaced by another module written from scratch.
In parallel to the different programming languages, there has been lots of UI paradigm changes. Writing a GTK app with a traditional UI (menubar plus toolbar) has become more and more difficult over the years, if not impossible with GTK 4. Imagine LibreOffice with a single "sandwich menu" - it's ridiculous.
The GTK developers develop GTK in their bubble, with gtk-demo as (almost) the only test application for GTK 4. There is no consultancy company knowing the needs of their users, and the GTK developers apparently don't listen enough to the application developers. It's a vicious circle.
Oh, and GTK 4.0 has just been released that they already think about GTK 5, another pile of API breaks around the corner. It's far from finished.
Without counting the fact that the MS Windows and macOS integrations are far from perfect. It works, more or less, but there are really sharp edges.
I know my criticism won't be appreciated, but I've *tried* hard, over the years, to improve things instead of sitting there and just complaining. My feeling is that I'm like a fish swimming up the river against the current.
Posted Dec 18, 2020 15:22 UTC (Fri)
by Xenophon (guest, #143699)
[Link]
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
I could probably find someone stating that verbatim buried in the many 300+ comment Gnome3 flamewar threads on this very site, but here's an evergreen starting point to set the mood:
https://trac.transmissionbt.com/ticket/3685#comment:4
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
627
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0
https://packages.debian.org/libudev0
GTK 4.0
think the maintainers would consider removing, say, a COBOL compiler or
an R charting library because it had no reverse dependencies.
have many things in the archive depending on it, it's as if there's a
default assumption that that was its only purpose.
GTK 4.0
GTK 4.0
(Version numbers taken from testing/unstable and the planned Debian 11 stable release; adjust downwards as appropriate for the Debian 10 stable release.)
GTK 4.0
https://access.redhat.com/articles/rhel-abi-compatibility...
https://access.redhat.com/articles/rhel8-abi-compatibilit...
GTK 4.0
GTK 4.0
GTK 4.0
GTK 4.0