GTK 4.0 [LWN.net]

GTK 4.0

Posted Dec 16, 2020 22:58 UTC (Wed) by fman (subscriber, #121579)
Parent article: GTK 4.0

They must me kidding right? *Another* GTK major release, just as the world was about to catch up with GTK3.

to post comments

GTK 4.0

Posted Dec 16, 2020 23:23 UTC (Wed) by flussence (guest, #85566) [Link] (15 responses)

The world already moved from GTK2 to Qt5, largely at the insistence of the GTK devs that GTK3 is for GNOME internal use only. They got what they wanted and I don't see that xenophobic attitude going away with this release.

GTK 4.0

Posted Dec 17, 2020 0:36 UTC (Thu) by compenguy (guest, #25359) [Link] (14 responses)

> largely at the insistence of the GTK devs that GTK3 is for GNOME internal use only

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.

GTK 4.0

Posted Dec 17, 2020 2:32 UTC (Thu) by liam (guest, #84133) [Link]

Possibly the section titled "Whose toolkit is it anyway?" from https://lwn.net/Articles/562856/ ?

GTK 4.0

Posted Dec 17, 2020 2:33 UTC (Thu) by flussence (guest, #85566) [Link] (4 responses)

>Source?
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

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.

GTK 4.0

Posted Dec 17, 2020 6:03 UTC (Thu) by joshl (guest, #91369) [Link] (1 responses)

> 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.

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.

GTK 4.0

Posted Dec 31, 2020 14:29 UTC (Thu) by flussence (guest, #85566) [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.

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?

GTK 4.0

Posted Dec 17, 2020 10:59 UTC (Thu) by pwithnall (subscriber, #97459) [Link] (1 responses)

You seem to be assuming that nothing has changed in the last decade.

GTK 4.0

Posted Jan 6, 2021 19:40 UTC (Wed) by efitton (guest, #93063) [Link]

Yes?

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.

GTK 4.0

Posted Dec 17, 2020 18:45 UTC (Thu) by ceplm (subscriber, #41334) [Link] (4 responses)

> Source?

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...).

GTK 4.0

Posted Dec 20, 2020 13:00 UTC (Sun) by scientes (guest, #83068) [Link] (3 responses)

There are people here complaining about how fast GTK 2.0 was deprecated, but the "web" hardly supports browsers more than 6 months old, and the performance of the web _as it is experienced_ is horrendus (although the CSS performance is pretty killer these days with Servo).

GTK 4.0

Posted Dec 21, 2020 1:07 UTC (Mon) by MrWim (subscriber, #47432) [Link] (2 responses)

I guess the point is that browsers support websites that are 30 years old. It means you can create something once and expect it to continue working long into the future.

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.

GTK 4.0

Posted Dec 21, 2020 7:16 UTC (Mon) by dvdeug (subscriber, #10998) [Link] (1 responses)

Browsers may support websites that are 30 years old, but not web programs that are 30 years old. ActiveX, Flash, Java applets, and Silverlight are all pretty much dead, and with them pretty much every "program" that was created for the web prior to around HTML5. I don't know how long this current wave of backward compatibility will last, but I don't think anyone should be touting 30 years of compatibility in the context of non-trivial web applications.

GTK 4.0

Posted Jan 2, 2021 15:55 UTC (Sat) by ryzokuken (guest, #115983) [Link]

None of the technologies that you mention are a part of the web platform, but are add-ons that are supported on specific web browsers in addition to the web features. The actual web platform is, and will always be, perfectly backwards compatible.

GTK 4.0

Posted Dec 18, 2020 11:18 UTC (Fri) by scientes (guest, #83068) [Link] (2 responses)

> The C++ API has made QT rather painful to bind from other languages.

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.

GTK 4.0

Posted Dec 18, 2020 19:33 UTC (Fri) by swilmet (subscriber, #98424) [Link]

I have the impression that using an API through a language binding never really feels like a native API, except if the binding has been created manually and tailored for the target language (but in that case it could be seen as a wrapper library, not a mere binding).

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).

GTK 4.0

Posted Jan 8, 2021 12:45 UTC (Fri) by bengen (guest, #14957) [Link]

Linking GTK to Go is not a particularly good example. Though I haven't got any experience with integrating GTK and Go programs specifically, I am certain from doing so with other C libraries that the GObject object system is not to blame here.

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.

GTK 4.0

Posted Dec 17, 2020 0:48 UTC (Thu) by atnot (guest, #124910) [Link] (5 responses)

Gtk4 is not a major release in the sense that Gtk3 was. Most applications will require very minimal porting, they've learned their lesson.

GTK 4.0

Posted Dec 17, 2020 10:06 UTC (Thu) by mchehab (subscriber, #41156) [Link] (2 responses)

> Gtk4 is not a major release in the sense that Gtk3 was. Most applications will require very minimal porting, they've learned their lesson.

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.

GTK 4.0

Posted Dec 17, 2020 11:56 UTC (Thu) by alexl (guest, #19068) [Link] (1 responses)

Why do you need to convert a pixbuf to a cairo surface to draw it? Just call gdk_cairo_set_source_pixbuf() to draw it onto the cairo_t.

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.

GTK 4.0

Posted Dec 17, 2020 12:05 UTC (Thu) by alexl (guest, #19068) [Link]

eh, subwidget, not subwindow

GTK 4.0

Posted Dec 18, 2020 14:33 UTC (Fri) by Vipketsh (guest, #134480) [Link] (1 responses)

If porting requires only "very minimal porting" why didn't they put in some "very minimal" work and make it no effort required ?

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.

GTK 4.0

Posted Dec 18, 2020 20:05 UTC (Fri) by swilmet (subscriber, #98424) [Link]

Why users of a library are often not also contributors of that said library? Because developers are busy enough with their own projects. Otherwise everybody would end up being kernel developers or physicians and mathematicians.

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.

GTK 4.0

Posted Dec 17, 2020 1:39 UTC (Thu) by Xenophon (guest, #143699) [Link]

GTK 3.0 was released over nine years ago, and the 3.x series is still being supported. GTK 2.x is only becoming unsupported now.

GTK 4.0

Posted Dec 17, 2020 1:41 UTC (Thu) by pabs (subscriber, #43278) [Link] (16 responses)

The world has definitely not caught up with GTK3 yet, there are lots of applications that will simply die when GTK2 goes away.

$ apt-cache rdepends libgtk2.0-0 | wc -l
627

GTK 4.0

Posted Dec 17, 2020 2:12 UTC (Thu) by ebassi (subscriber, #54855) [Link] (15 responses)

I'm sure that Linux distributions will keep GTK2 in their repositories for a long time; I think some of them still ship GTK1, which hasn't been touched in nearly 20 years.

GTK 4.0

Posted Dec 17, 2020 3:11 UTC (Thu) by pabs (subscriber, #43278) [Link] (13 responses)

I note that Debian is planning on removing GTK2 for Debian 12 bookworm, to be released in 2-3 years time and starting sometime next year after the Debian 11 bullseye release.

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.

GTK 4.0

Posted Dec 17, 2020 3:18 UTC (Thu) by ebassi (subscriber, #54855) [Link] (5 responses)

Then this is a great chance to start using Flatpak to ensure that GTK2 (and GTK1!) applications can still be used on newer versions of your favourite Linux distribution.

GTK 4.0

Posted Dec 17, 2020 3:31 UTC (Thu) by pabs (subscriber, #43278) [Link] (4 responses)

Aren't the GTK2/GTK1 Flatpak runtimes going away too? Either way, the maintainers of software still depending on GTK2/GTK1 haven't bothered to migrate to GTK3/4, I doubt they will bother with Flatpak packaging either.

GTK 4.0

Posted Dec 17, 2020 9:25 UTC (Thu) by smcv (subscriber, #53363) [Link]

If GTK 2 apps are sufficiently important to you, I'm sure your help would be appreciated. The people packaging GTK 2 apps as Flatpak apps don't *have* to be their upstream maintainers, any more than the people packaging GTK 2 apps for Debian have to be their upstream maintainers.

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.

GTK 4.0

Posted Dec 17, 2020 14:16 UTC (Thu) by ebassi (subscriber, #54855) [Link] (2 responses)

> Aren't the GTK2/GTK1 Flatpak runtimes going away too?

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.

GTK 4.0

Posted Dec 18, 2020 6:50 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

But GTK2 has reached end of life, so you can’t bundle it. If you say, this end of life stuff is nonsense, there is no reason not to keep shipping the library, then you may equally well ship it as an rpm or deb package. I don’t see that using Flatpak makes a difference either way.

GTK 4.0

Posted Dec 18, 2020 12:23 UTC (Fri) by smcv (subscriber, #53363) [Link]

> But GTK2 has reached end of life, so you can’t bundle it

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).

GTK 4.0

Posted Dec 17, 2020 7:25 UTC (Thu) by epa (subscriber, #39769) [Link]

The dillo web browser was using GTK 1, but moved to FLTK instead when GTK 1 died.

GTK 4.0

Posted Dec 17, 2020 9:45 UTC (Thu) by smcv (subscriber, #53363) [Link] (5 responses)

> planning on removing GTK2 for Debian 12 bookworm

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.

GTK 4.0

Posted Dec 17, 2020 20:59 UTC (Thu) by mattheww (guest, #108205) [Link] (4 responses)

I have a question:

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.)

GTK 4.0

Posted Dec 18, 2020 1:41 UTC (Fri) by pabs (subscriber, #43278) [Link] (2 responses)

Normally Debian doesn't consider packages not in Debian when doing removals, since the person requestion removal usually doesn't have visibility into that.

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
https://packages.debian.org/libudev0

GTK 4.0

Posted Dec 18, 2020 10:27 UTC (Fri) by mattheww (guest, #108205) [Link] (1 responses)

It seems to me that Debian has something of a blind spot here. I don't
think the maintainers would consider removing, say, a COBOL compiler or
an R charting library because it had no reverse dependencies.

But when they're looking at a piece of software which historically did
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

Posted Dec 19, 2020 1:31 UTC (Sat) by pabs (subscriber, #43278) [Link]

Things get removed from Debian due to lack of reverse dependencies all the time. The first class of these are modules in various languages (Node/Python/Perl etc) that are often just removed by the respective language team when nothing in Debian uses them and they don't have significant popcon. The second class is things that gather an critical bug that is trivial to fix, often they will just be removed instead of fixing the bug. Unfortunately Debian QA folks are significantly deletionist, since removal is less effort in the long term than fixing issues.

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.

GTK 4.0

Posted Dec 18, 2020 12:10 UTC (Fri) by smcv (subscriber, #53363) [Link]

> 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?

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.
(Version numbers taken from testing/unstable and the planned Debian 11 stable release; adjust downwards as appropriate for the Debian 10 stable release.)

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.

GTK 4.0

Posted Dec 20, 2020 8:53 UTC (Sun) by ms_43 (subscriber, #99293) [Link]

GTK 2 is on RHEL 7's list of Compatibility level 1 packages[0].

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)
https://access.redhat.com/articles/rhel-abi-compatibility...

[1] Compatibility level 2: APIs and ABIs are stable within one major release
https://access.redhat.com/articles/rhel8-abi-compatibilit...