GTK 4.0 [LWN.net]

GTK 4.0

Posted Dec 17, 2020 0:36 UTC (Thu) by compenguy (guest, #25359)
In reply to: GTK 4.0 by flussence
Parent article: GTK 4.0

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