Even though Gtk3 is still riddled with regressions compared to Gtk2, and there's no stable theme interface, and for example the Raleigh theme engine completely broke in 3.20, the GNOME devs seem to have decided to take it to the next level.
That means, unless I'm reading things wrong, this is the gist:
1. API and ABI breakage twice a year
2. Applications that have been linked for 4.2 on a system with 4.2 dev files installed will still run when the system gtk4 is 4.4. But you're not allowed to build a 4.2 app anymore once 4.4 is on the system. This means, the 4.2 .so can exist in parallel but not the development files. Those are allowed to exist for only one gtk4 release.
3. (2) combined with (1) is a nice way to prevent adoption
Now, this may sound rude, but given the state of Gtk3 after 10 major releases and the overall way devs have dealt with the community, I must say I welcome this, because it can be a nice motivator for everyone that still believed in Gtk3 to look at Qt.
* Wireshark has a Qt frontend now
* wxWidgets has a Qt backend now (experimental for now)
* mkvtoolnix is Qt only now
* the list goes on
If anyone believes developers ported from Gtk2 to Qt for fun, please consider the effort it takes.
Yes, gtk2 has limitations, but there was ABI and API stability on all layers. Since gtk3, the development model seems to be inspired by web applications in that breakage is frequent and stability is mostly not guaranteed. It starts with drawing regressions and extends to a theming api which is unstable and therefore could also not exist, because each theme has to exist for each major gtk3 version.
Had Gtk3 only added Wayland and HiDPI support, and kept API stability for the most part, we wouldn't find ourselves in this unfortunate situations. Since, more than a few applications have migrated to Qt.
I don't like some of the things in Qt5 like the file selector, but that's a minor nuisance for avoiding gratuitous regressions.
I have to use Firefox ESR because the switch to Gtk3 broke too much in the UI (in addition to general non-existence of stable Gtk3 themes).
I feel like a well-executed Gtk2 fork could be very popular. I checked and MATE uses Gtk3—I thought it had forked Gtk2 along with GNOME2, but apparently not.
GTK development is done by the people that show up to do the work and contribute patches. That happens to be, by and large, GNOME developers.
The best way to affect GTK development is to either 1) show up for hackfests (like this week in Toronto), 2) join in on IRC where we plan things, 3) work on bugs, submit patches, etc
I've been working on GTK for the better part of two decades, and employed by Red Hat for about 9 months. They have in no way ever influenced my contributions (I've barely ever been to an office). My contributions were just as many before my employment as they are now.
My suggestion would be to join in on #gtk+ and make your voice heard this week while we plan out the next year of work (unless you are Toronto based, and then just join in person).
> 2. Applications that have been linked for 4.2 on a system with 4.2 dev files installed will still run when the system gtk4 is 4.4. But you're not allowed to build a 4.2 app anymore once 4.4 is on the system. This means, the 4.2 .so can exist in parallel but not the development files. Those are allowed to exist for only one gtk4 release.
The point here is that all of these would link against something like "gtk-4-unstable.pc" which makes things easy for distributions to know what needs to be recompiled when they bump dependencies.
So while it semantically is the case, I don't think it is as big of a deal as you are claiming.
> Even though Gtk3 is still riddled with regressions compared to Gtk2
Gtk 2 hasn't changed in over 5 years. So I'm not sure it's suitable to compare against anything.
> and there's no stable theme interface, and for example the Raleigh theme engine completely broke in 3.20, the GNOME devs seem to have decided to take it to the next level.
The stable theme API landed in 3.20. That is a first time in my nearly 18 years of working with GTK. While the Raleigh didn't "completely break" as you say in 3.20, it hasn't been the "default" GTK theme for quite some time.
> Yes, gtk2 has limitations, but there was ABI and API stability on all layers.
I worked on one of the largest gtk2 applications shipped to date (the VMware Linux product line) so I have a little background on the topic. I also happen to be an upstream GTK developer now since I left VMware 5 years ago.
And, quite frankly, this statement is incorrect. Plenty parts of GTK 2 were unstable during it's lifetime. In particular theming and gtkrc bits. I've written enough workarounds during the lifetime of gtk2 products to know. That is simply the reality when a piece of software tries to remain ABI stable for over a decade. It's really, really, really hard work (and as this post shows, almost completely thankless).
The only reason gtk2 is stable today, is because it's generally not touched (except for very specific bug fixes).
You'll see gtk3 be considered stable in the near future, but with a longer lifetime of bug fixes than gtk2 has gotten. Some of us are arguing for in 6 months, some for a year'ish. Meanwhile we will develop and stabilize gtk4 to land in the next series of long lifetime releases. We haven't hashed out all the details yet, but that could mean that if you subscribe to our 6 month release cycle, you might depend on say "gtk-4-unstable.pc". Where as, once we start on gtk 5, you can depend on "gtk-4.pc" and everything is guaranteed stable going forward. Those on the GTK release cycle will then consider moving to "gtk-5-unstable.pc".
By moving our major numbers sooner, it's very clear that the major version you are on is no longer game for major changes. I wish we had a butter way to deal with what we call the numbers (4.6 being 'stable' for example), but semantic versioning here isn't really sufficient (nor simply soname versioning alone).
We couldn't really come up with a better naming system than to say something like "4.6 is considered stable". This is a complex problem because we can either require everyone to bump their pkg-config dependencies again once they know they are stable, or not. We discussed doing something like 4 stable and 5 development, 6 stable, etc but ultimate decided against (as much as a half day decision can be) due to the churn it would take maintainers to update build system.s
This is mostly made more difficult because of distributions. They often deal with packages that are written and then stagnate for a couple of years and would like them to keep working (Debian Testing → Stable for example).
We've only discussed this for half of day-one of our current hackfest, so of course, if you have input, this would be a great time to join #gtk+ and make your voice heard. Many of us are here i...
> Plenty parts of GTK 2 were unstable during it's lifetime.
I've written a Raleigh theme more than 12 years ago, and that one still works as it did back then.
I believe you when you say not all parts of Gtk2 were stable and some stuff was surely evolving, but the overall I've seen no regression in Gtk2 as I did in Gtk3.
That said, if Gtk3 has only been considered stable since 3.20, then more appropriate versioning/communication might have been useful, but I doubt that's what you're saying.
Also, I know I have too little domain knowledge to judge what it takes to support HiDPI and Wayland, but what I do object is focusing on too many things for a major release. What works better are time based releases where, if one feature branch misses the release, it'll arrive in a later version. Full rewrite efforts seldom work out.
You said Raleigh should work in 3.20, I just tried to use it as the 3.20 theme again and it's still borked compared to 3.18, but it's unsurprising if it's not the default and probably untested.
But what's more important is that Gtk2's Raleigh looks really nice, whereas 3.20's Raleigh looks like it's deliberately made to look worse, which is hard to understand, given that the drawing code is supposed to be 99% unchanged, if I look at Gtk2 to Gtk3 porting guides.
> That said, if Gtk3 has only been considered stable since 3.20, then more appropriate versioning/communication might have been useful, but I doubt that's what you're saying.
The theming API is what I was regarding as stable come 3.20. (CSS elements are finally documented, for example). And you are right, we could have done a better job of communicating it. It was obvious to those of us who work with GTK every day, (and theming has been unstable since gtk2 was released as it required C code), but it wasn't stated in large block print anywhere. We could have done better. To help with this we started, a few weeks ago, a new GTK blog to help people stay up to date. (blog.gtk.org)
> Also, I know I have too little domain knowledge to judge what it takes to support HiDPI and Wayland, but what do object is focusing on too many things for a major release. What works better are time based releases where, if one feature branch misses the time window, it'll arrive in a later point release. Full rewrite kinda efforts seldom work out.
Gtk3 has been large parts of rewrites done in short 6 month increments. That said, writing things like a full CSS 3 implementation that themers asked for is no small task. And making a modern toolkit that ships in 5 years does not do Free Software a service if it's too late to be useful. We've been trying to strike the right balance, but it takes developers testing things during the development cycle to really make that possible. Unfortunately, GNOME is pretty much the only project doing thate.
> Finally, I just tried to use Raleigh as the 3.20 theme again and it's still totally borked compared to 3.18, but it's unsurprising if it's not the default.
We should probably remove it from the list, to be honest. Adwaita "is the GTK theme", not Raleigh. I can add this to tomorrows topics at the hackfest.
> But what's more important is that Gtk2's Raleigh looks really nice, whereas 3.20's Raleigh looks like it's deliberately made to look worse, which is hard to understand, given that the drawing code is supposed to be 99% unchanged, if I look at Gtk2 to Gtk3 porting guides.
The drawing model of gtk2 and gtk3 are completely different. The themes are CSS now so the Raleigh theme, at minimum, has been ported from C code to CSS.
One thing regarding theming: I quite like theme engines that implement the drawing code in C because there's a lot more flexibility and room for performance. It's also how proper emulations of other operating systems' looks was achieved without an unresponsive set of bitmaps. The general purpose'ness of CSS will inevitably have limitations that either restrict what can be drawn or how efficient it can be made.
> One thing regarding theming: I quite like theme engines that implement the drawing code in C because there's a lot more flexibility and room for performance.
As a long time C and assembly hacker, I certainly know the feeling. However, with were we are going, we have evidence we can do faster on the GPU with various shaders than any of us can do with hand written assembler these days. I anticipate gtk 4.x rendering to vaguely look like webrender (which if you squint hard enough, looks similar to clutter 2.0 design).
> It's also how proper emulations of other operating systems' looks was achieved without an unresponsive set of bitmaps. The general purpose'ness of CSS will inevitably have limitations that either restrict what can be drawn or how efficient it can be made.
Our CSS engine does support SVG for scalability just fine with "bitmaps". The most difficult part of the current win32 theme work (partially landed in 3.20) is that we have lots of widgets that there is simply no analogous in win32. So making a "on|off" toggle look like win32 isn't exactly clear. I haven't tested the new theme on win32, but I do think a bunch of it is improved (note that running the win32 theme on Linux is not the same as running the win32 theme on win32, it requires some internal windows API for some of its features).
> we have evidence we can do faster on the GPU with various shaders than any of us can do with hand written assembler these days
While true, the same shader can be written and incorporated in an engine written in C.
The most important feature is API stability so that good themes can be created. For example, some Gtk2 scrollbar settings like the arrow buttons seem to be gone in Gtk3. Is the idea that scrollbars should be drawn and callbacks implemented in JavaScript for arrow buttons?
>> we have evidence we can do faster on the GPU with various shaders than any of us can do with hand written assembler these days
> While true, the same shader can be written and incorporated in an engine written in C.
This is not true, unless you do all the same plumbing. We have two major pieces of evidence for this:
1) gtk-theme-engines from 2.x days almost universally caused crashes in applications when the did stuff wrong (and they all did)
2) You can't hide the details of the GPU pipeline behind a theme. it really changes the entire model of the application, how you store and cache state, how you pass it to the GPU, when you deliver that information, etc.
> The most important feature is API stability so that good themes can be created.
This is exactly why we want to have a stable release that wont be getting breaking changes. We think, practically, that most application developers will target the stable release (and therefore the stable themes). We think the primary users of unstable will be GNOME applications or other desktops that choose to align themselves with the GTK unstable cycle.
> For example, some Gtk2 scrollbar settings like the arrow buttons seem to be gone in Gtk3. Is the idea that scrollbars should be drawn and callbacks implemented in JavaScript for arrow buttons?
I'm not totally up to date on context here, bugzilla would be the best place to discuss this further.
If your theme engine is as simple as Raleigh, then the chances of crashing applications because of a bug in the theme are smaller. Sadly, most (if not all) theme engines were far, far more complex than Raleigh.
We have bug reports coming especially from people using the Oxygen theme, which had a tendency to (against all recommendations) poke at the widget structure behind the style contexts because what could possibly go wrong.
Given the ability to inject random C code into applications that do not expect that, people will abuse it; hence the switch to a pure declarative language like CSS to describe the aspect of widgets. Your app may look like crap, but it won't crash because of that.
I agree, though none of the theme engines I've used regularly crashed. There were two KDE theme engines which managed to crash in their gtk variant, but those had more issues than that. No crashes whatsoever with all of gtk2-engines and also murrine or aurora.
This is why I've resorted to looking for things based on Qt rather than Gtk. I cannot fathom what the Gnome team has for their "target" or "typical" user, I'm guessing it's some sort of unholy love child between MacGyver and a Brown Motie.
I recently learned that there is a continuation of KDE3 out there, called Trinity. Complete with a maintenance fork of Qt3. They seem to even having maintained the structuring of the KDE3 source releases, so that rolling ones own install quite straight forward. Its either that or give up on the DEs completely and adopt a WM (IceWM seems tempting).
I use a window manager (or Wayland compositor) with select GUI apps and no desktop environment, so I'm not the customer of the GNOME or KDE projects. I don't have a 4k screen, so the, from my perspective, wasted vertical screen estate in Gtk3's supported and promoted style is a usability disaster for me. As I wrote in a sibling comment, I've been using the same Gtk2 theme I wrote more than 12 years ago and never had the urge to change it because the behavior and color scheme of that Gtk2 Raleigh mod suit me well. With Gtk3 I had managed to kinda imitate that despite the limited emulation in CSS of Raleigh, but in 3.20 it all blew up for me (even vanilla Raleigh).
So this is an ass backwards way of saying that GTK releases are going to be in beta for 2 years and the real releases are going to be called gtk4.12 instead of gtk4
On one hand okay fine. On the other hand this is ass backwards: just admit you're doing beta releases.
No. What it seems like is that they want more flexibility while developing GNOME (6 month cycle as it is now), and provide some stability for outside users of GTK+ too (2 year cycle).
Beta releases are done within the regular 6 month cycle.
The extraction of the toolkit from GIMP was done as the early pioneering of GNOME. Before that, it wasn't really a toolkit. I mean, it was an in-application toolkit, but that is very different from a usable toolkit.
Perhaps the authors of the toolkit are better positioned to judge what the release policy and development approach should be. They take long term stability requirement of outside parties into account with this new approach.
I'm not sure why they couldn't use the benefit of being in control of the toolkit while developing GNOME, and write some adapter layer, like KDE.
It sounds to me like they really just want to do more point releases. Perhaps they could simply make a GTK-dev or something rather than calling it 4.0 which isn't gtk4.
We considered doing something like x.y up to z.0. But that would require that developers bump their soname multiple times if we want them to port before the toolkit is considered long term stable. It's an awful lot of work to put on developers. We are trying to give them the best of both worlds, with the only variable being the time in which they chose to move.
"Gtk4 API will not be stable at Gtk4.0" or the original title would be better. 'Discouraging portable Gtk apps' isn't mentioned in the original article or LWN.
Editors, can you fix the title of this post to match what it links to: "Lortie: Gtk 4.0 is not Gtk 4".
The linked post is a rather confusingly written way of saying that Gtk 4.6 will have a stable ABI but that Gtk 4.0-4.5 won't (and thus shouldn't be used outside GNOME, if I understand it correctly).
I already have gtk2, gtk3, qt4, qt5 installed on my linux machine, the situation which I really hope to get rid of.
And now GNOME devs hope user to install gtk2, gtk3, gkt4, gkt5, gtk6 at the same time to solve imcompatibility. Nice try.
You could have a system that has broken software instead?
But seriously, giving multiple years between the major versions is a lot of time in between for applications to port forward (or they can choose the version they want to stay on) and enough time to stabilize features that take more than 6 months to write. Turns out writing whole new rendering engines takes some time and testing and can't be flipped on as fast as javascript frameworks materialize.
If applications want to stay on a stable version for 5 years or more, that all of a sudden becomes tenable which wasn't the case before unless you wanted to stick to gtk2, which is right out of 1998 "how to write a toolkit".
This isn't very different from other systems that bump the soname and have multiple versions based on what ABI, as required by the applications. I'm sure you have multiple of these on your system already. The reason soname isn't enough for GTK has to do with parallel installability of headers, bindings, etc etc
There is no guarantee that the good software you are using have someone maintaining it or interested in porting it, which is really common in open source word. For me they are Texmacs which only have bug fixes nowadays and a bunch of browser plugins whose producer are not willing in porting them.
The serious problem here is that, What this plan shows is a total lack of concern. Doing rolling release for a distribution is OK, but for a fundamental library this is unacceptable. Qt has been doing much better on this.
FWIW, Qt has been bumping major versions more often than us as well.
It really comes down to ensuring that developers are shipping a known quantity. They should be shipping with a set of libraries that were actually tested.
It's unreasonable to expect the toolkit authors to be able to test every possible permutation on every release unless people stand up to run build bots, automated testing, and report back to us when things break.
Keeping your Texmacs, for example, working in 5+ years time is important to us. That is why we want to give it a stable API that only gets bug fixes after a certain time frame. Is that such a bad idea? Would you really expect to magically get touch, HiDPI support, etc on a 5 year old application when you never changed your application code?
> For a fundamental library like this devs should at least keep core api stable for a long time, and release unstable components seperately.
This is something we'd like to get to (say external widget libraries). But it requires, guess what, an ABI break :)
> As I have stated, I really don't like a large number of similar libraries installed on my machine, each with a bunch o dependencies.
This is a long running "problem" on GNU/Linux. I've been around for a couple of decades and the problem has existed pretty much the entire time. We all have some holy grail of design in how we'd like the world to be and are disappointed it isn't what we think it should clearly be.
I'm not saying your viewpoint isn't valid, just that I'm not sure you can put the necessity to solve it on our shoulders.
As a gentoo user I would say that the ABI break may still worth it if it can enable a lot of application continuing to work with just a recompile, right?
The controversial around this plan origins from people's inability to understand why such a fundamental library like gtk+ needs to have api break in such a high frequency, which would have a huge impact on the experience of app devs and users? The world has its intrinsic complications, but we all hope to avoid the casual one.
> As a gentoo user I would say that the ABI break may still worth it if it can enable a lot of application continuing to work with just a recompile, right?
Yes, just a recompile in all the cases we've really discussed. However, if we can break ABI in minor releases, we have contemplated the idea of installing private headers to allow developers to "do wtf they want" with a I_KNOW_WHAT_IM_DOING #define or something.
But the important thing, is to test the software!
> The controversial around this plan origins from people's inability to understand why such a fundamental library like gtk+ needs to have api break for such a high frequency, which would have a huge impact on the experience of app devs and users? The world has its intrinsic complications, but we all hope to avoid the casual one.
That is the thing. We are a very small team of mostly part time contributors trying to build a toolkit that competes with the big players, who have teams the size of hundreds. There is a lot of work to do, with an insane cadence required.
I don't think this isn't really any different than choosing your target device version for say, iOS, Android, or macOS. They likely are likely breaking subtle things in-between major releases too, but you can either 1) lock to a version or 2) upgrade and fix-the-world.
> No it's not. In case of device only a small bunch of things break. For gtk+ everything breaks without a fix.
That's because about every other year they have the equivalent of a major ABI break (and they you target explicitly the newer version or stay locked to the old version) and the platform ships both.
Just so I understand, would the ideal goal in that scenario be fat app packages or maybe even statically linked apps? If the API/ABI support scheme as blogged about is adopted, maybe that's the practical solution.
Am I wrong, or does this sound like GNOME's trying to be a more central runtime and subsume parts of a linux distro in full. If that's true, it certainly doesn't sit well with me, if I consider how and why I've been using Linux for 19 years. I've never been able to use a desktop environment because they're always limited and do not allow me to express my way of working like my old FVWM config or current XMonad config do. It's like the difference between SublimeText and Emacs users. Different needs mean different types of users and Gtk and Qt must stay GUI toolkits, two among many.
> Am I wrong, or does this sound like GNOME's trying to be a more central runtime and subsume parts of a linux distro in full.
I don't think so, but GNOME does have a long history of diving down the stack and fixing problems when we run into them in lower levels. Of course, fixing long standing bugs that are often depended on corner-cases is certainly going to require additional engineering (the current tmux/screen situation comes to mind).
These things are largely a thankless task, and often a hostile process. Everyone seems to want their bug fixed, and nobody elses.
We very much need everyone interested in our shared commons to come to the table and discusses their needs. Otherwise it's not a commons.
If we were going to completely rely on flatpak to solve our problems, we would be able to break ABI every 6 months w/ each GTK release. But that is not a tennable solution today (or likely ever). Distributions ship desktops which will have applications that naturally live outside the flatpak runtimes.
This makes it sound like there is no plan. Rather than coming up with a defined API first, then implementing it through normal alpha, beta, rcs. They are just going to start writing whatever code at gtk4 and the stable version wont be until something like gtk4.xx based on whatever they decided to write.
And after gtk4.xx is released, are bug fixes supposed to happen on the newly unstable gtk5? -- I'm so confused.
Considering this was half a day at our first hackfest of the season, I'm not surprised it doesn't sound fully fleshed out. Nor should it be this early. I'm mostly just surprised how much steam it's picked up on the commentary sites.
But that said, it's not that we don't have a plan. We have a very concrete plan in moving to a GL renderer, render trees, shader-based CSS drawing, and more. However, that necessarily means breaking the imperative drawing model that has us stuck in 1998.
So what are we to do?
Version numbers are just a thing. I think semantic versioning makes people put a little bit more confidence in what they are than its worth, but we did discuss this quite a bit.
We have a few options, some of which might be a "gtk-4-unstable.pc" pkg-config, or bumping soname more (but if we do that, why not bump the major number too), etc etc. We are all long term Free Software veterans maintaining long running ABI software projects. We are certainly thinking about the consequences of our choices from a developer, user, and distributor viewpoint.
Yes, and they should mean something. Not having a fixed API/ABI for an entire major version goes against what everyone else thinks that version numbers mean. You can talk yourself into thinking that the numbers don't matter - that only the semantic versioning (whatever that is) matters. But that doesn't mean that everyone else will agree, let alone understand what the hell you're talking about.
The situation with 4.0 not being 4.x is most certainly the most contentious part of the discussion so far. It is also subject to change (it's only been a few hours so far of us discussing this).
That said, if we can't guarantee the minor versions as we drain the swamp to rebuild this toolkit into something modern, we either need to not release anything (which makes it very hard to build if you can't get users to test things) or we need to come up with alternate versioning schemes.
I was always a fan of the older linux model: x.1 = unstable, x.2 = stable, x.3 = unstable, x.4 = stable.
Really, the reason why this strikes a chord is that it is confusing as hell. What is the rationale behind not allowing a 4.2 project to be built once 4.4 is installed on the system? That is the truly confusing part. Are you expecting that many backwards incompatible changes between 4.2 and 4.4? Why do the headers and packages need to share the same namespace?
I'm sure a lot of thought went into this, but something just doesn't seem right to me...
> I was always a fan of the older linux model: x.1 = unstable, x.2 = stable, x.3 = unstable, x.4 = stable.
This certainly came up in our discussions... I think many people were left with a bad taste in their mouths due to trying to decode Linux version numbers. In my opinion, anything that has an actual decode algorithm would be better than the current situation of ... i dunno? :)
> Really, the reason why this strikes a chord is that it is confusing as hell. What is the rationale behind not allowing a 4.2 project to be built once 4.4 is installed on the system? That is the truly confusing part. Are you expecting that many backwards incompatible changes between 4.2 and 4.4? Why do the headers and packages need to share the same namespace?
I think this was miscommunication to be honest.
The installation headers for 4.0, 4.2, 4.4, etc will not be parallel installable based on the current idea. So when your distribution upgrades to 4.4, anything you compile against the -devel headers will be for 4.4. However, if they keep the previous soname version for 4.2, I don't see any reason that program couldn't keep working.
Of course, we could try to discover the ABI incompatabilities with libabigail, but history has shown us (over the last couple years) that there is a lot to ABI breakage that has nothing to do with symbols. Theming, expected behavior...
> I'm sure a lot of thought went into this, but something just doesn't seem right to me...
We certainly appreciate feedback. We are trying to be reponsive on irc.gimp.net #gtk+ during the hackfest, and your concerns will be relayed to the group. We are a fairly small group of about a dozen people, but gtk+ is important to us and we care about improving things.
I do. It seems to have far better versions of the main widgets I need, and far more opportunities for binding (GTKmm ftw). Plus, unlike many, I /like/ how my programs look the same on all platforms; screw having to test every pixel of detail on 3+ different native drawing APIs. These are just off the top of my head. Sure, I'm seeing the teething troubles of 3.20, but hey: I'm helping where I can, and I see it's getting better at a rapid rate. Qt on the other hand just doesn't grab me, both in capabilities and stylistically, though that might change, especially as they're starting to think about, y'know, actually being C++.
I had a sour taste in my mouth when I read this, but I can sort of see it. It reminds me of Ubuntu's release pattern - 3 unstable releases then 1 stable release alternating. The only difference is that the major number changes for the first unstable release. (Makes sense. The point-oh release is unstable, the stable release has a big number on the end.)
I think the controversy is that, when I read this, I get the impression that GNOME devs either don't believe that backwards compatibility is possible in the long run, or that it's at least unpractical. I don't really get that impression given QT's backwards compatibility, MFC, etc, but if they really believe it, then faking it is unproductive, and just making a more distro-like release plan is reasonable.
I really can't get the distro comparison out of my head - it's like they tried a single release that lasted forever, and that didn't work, so they tried a rolling release, and that didn't work, so now they're going with unstable releases with LTS releases every 2 years.
I feel like they could have saved themselves an immense amount of pain in the comments if they'd just called the alpha releases ("4.0", "4.2", "4.4") like the are; they quack like a duck. Why is 4.0-alpha.1, 4.0-alpha.2, etc., so hard?
The average developer does not think "oh, 4.2; that's an alpha release", they think it's two iterations on 4.0.
This is important. In a release scheme where a new version is out regularly, you want to be able to easily point to specific, stable, old version by just saying "this has been available since GTK 27" instead of having to know that at the 27 major number, the stable version is 13, so you need that specific knowledge to be able to say "this has been available since GTK 27.13". The RC, alpha, beta releases are just steps towards the stable release, which is the only version that remains.
More and more when i see a Gnome dev write about empowering "upstream" i replace it with empowering Gnome. They are hung up on user experience so much that they want one, canonical (heh), Linux distro that they get to define. Fedora, suse, Debian, Arch, it will be all the same with a different sticker on top.
And they have the backing of RH in this, by way of Fedora and Freedesktop.
Lets not forget that Freedesktop was actually founded by Havoc Pennington while working at RH on desktop matters. Frankly Freedesktop do not exist to actually foster interoperability. it exists to whitewash RH decisions.
For me, Linux is better when there is a distinction between kernel, user space (and its various parts), X, and the DE/WM.
The direction things are going right now means tightening integration by using systemd as the glue, and Gnome as honey. All to lure distros in and get them stuck like flies on, well, flypaper.
> Lets not forget that Freedesktop was actually founded by Havoc Pennington while working at RH on desktop matters. Frankly Freedesktop do not exist to actually foster interoperability. it exists to whitewash RH decisions.
This is ludicrous to anyone who has worked at Red Hat at some point in their career. Red Hat internally is almost a perfect mirror of the community at large. There are thousands of differentiating viewpoints on pretty much any topic related to Free Software (including if we should call it Free Software).
The group of people working on desktop at RH are quite small, it's not the cabal you seem to imply.
> All to lure distros in and get them stuck like flies on, well, flypaper.
We're trying to build a modern operating system where the components are part of a whole. I'm sorry you feel that is some sort of trap. That is not the intention, in any way.
Qt's backward compat story is great and not so great. It's BC and sometimes SC but the fact is they keep breaking behavior even in patch releases. If you develop with Qt for a long time, you realize that BC is simply not good enough and you start static linking (a process they have made quite hard with Qt5).
I've noticed that some projects don't link statically anymore with Qt 5.6 but others do. I believe the CMake scripts are insufficient while qmake projects works most of the time but also not always. I haven't figured it out. If you have links with more info, I'd be curious. Also, I take it it's not possible to configure a Qt5 build to produce .so and .a files, or am I wrong?
I don't see the big problem. Lots of other libraries already work this way. Perhaps most of them.
If you're shipping binary packages, you need to build them in a clean chrooted environment anyway (such as pbuilder/sbuilder/docker or a VM) or you're going to end up with binaries that depend on the latest glibc point release that happens to be installed on your system.
> depend on the latest glibc point release that happens to be installed on your system.
glibc doesn't break API dramatically with each new version ... Gtk does and that's an insane burden put on developers using that thing. You can't develop stable tools with an ecosystem that keeps on breaking. Why should I bother with Gtk when I can learn a more stable GUI framework ? that's right, and I don't. Then the Gnome Foundation complains people aren't using Gtk ... I see a lot of Gnome projects started then abandoned, only to see a new project doing exactly the same thing being built from scratch afterwards. For instance, they are working on a new IDE Gnome builder, who the hell needs this when multiple projects like Gedit get very little contribution today ? To me the Gnome foundation is wasting money with all that stuff, while investing very little in the documentation for instance. Their website is a mess.
> I see a lot of Gnome projects started then abandoned, only to see a new project doing exactly the same thing being built from scratch afterwards. For instance, they are working on a new IDE Gnome builder, who the hell needs this when multiple projects like Gedit get very little contribution today ?
"They" → me
Like seriously, me. It's not the GNOME foundation. They've given me no money. I do get occasionally contributions from the same people that build Gedit. I also spent most of a decade contributing to another well known IDE for Mono. So this isn't my first rodeo.
A significantly amount of work I've done on Builder HAS flowed upstream into both GTK and Gedit, so clearly you have no clue what you're talking about.
> To me the Gnome foundation is wasting money with all that stuff, while investing very little in the documentation for instance. Their website is a mess.
Again, your money to the foundation has never gone to Builder, but I also hope to have a large demo regarding documentation to show at GUADEC, should you choose to attend.
76 comments
[ 2.9 ms ] story [ 108 ms ] threadThat means, unless I'm reading things wrong, this is the gist:
1. API and ABI breakage twice a year
2. Applications that have been linked for 4.2 on a system with 4.2 dev files installed will still run when the system gtk4 is 4.4. But you're not allowed to build a 4.2 app anymore once 4.4 is on the system. This means, the 4.2 .so can exist in parallel but not the development files. Those are allowed to exist for only one gtk4 release.
3. (2) combined with (1) is a nice way to prevent adoption
Now, this may sound rude, but given the state of Gtk3 after 10 major releases and the overall way devs have dealt with the community, I must say I welcome this, because it can be a nice motivator for everyone that still believed in Gtk3 to look at Qt.
* Wireshark has a Qt frontend now
* wxWidgets has a Qt backend now (experimental for now)
* mkvtoolnix is Qt only now
* the list goes on
If anyone believes developers ported from Gtk2 to Qt for fun, please consider the effort it takes.
Yes, gtk2 has limitations, but there was ABI and API stability on all layers. Since gtk3, the development model seems to be inspired by web applications in that breakage is frequent and stability is mostly not guaranteed. It starts with drawing regressions and extends to a theming api which is unstable and therefore could also not exist, because each theme has to exist for each major gtk3 version.
Had Gtk3 only added Wayland and HiDPI support, and kept API stability for the most part, we wouldn't find ourselves in this unfortunate situations. Since, more than a few applications have migrated to Qt.
I don't like some of the things in Qt5 like the file selector, but that's a minor nuisance for avoiding gratuitous regressions.
I have to use Firefox ESR because the switch to Gtk3 broke too much in the UI (in addition to general non-existence of stable Gtk3 themes).
The basic problem is that most of GTK development is happening "thanks" to Gnome and Red Hat, and they are gung ho about GTK3.
In essence, how the fuck do you keep going when the 800lb gorilla wants to go in a different direction?
The best way to affect GTK development is to either 1) show up for hackfests (like this week in Toronto), 2) join in on IRC where we plan things, 3) work on bugs, submit patches, etc
I've been working on GTK for the better part of two decades, and employed by Red Hat for about 9 months. They have in no way ever influenced my contributions (I've barely ever been to an office). My contributions were just as many before my employment as they are now.
My suggestion would be to join in on #gtk+ and make your voice heard this week while we plan out the next year of work (unless you are Toronto based, and then just join in person).
The point here is that all of these would link against something like "gtk-4-unstable.pc" which makes things easy for distributions to know what needs to be recompiled when they bump dependencies.
So while it semantically is the case, I don't think it is as big of a deal as you are claiming.
> Even though Gtk3 is still riddled with regressions compared to Gtk2
Gtk 2 hasn't changed in over 5 years. So I'm not sure it's suitable to compare against anything.
> and there's no stable theme interface, and for example the Raleigh theme engine completely broke in 3.20, the GNOME devs seem to have decided to take it to the next level.
The stable theme API landed in 3.20. That is a first time in my nearly 18 years of working with GTK. While the Raleigh didn't "completely break" as you say in 3.20, it hasn't been the "default" GTK theme for quite some time.
> Yes, gtk2 has limitations, but there was ABI and API stability on all layers.
I worked on one of the largest gtk2 applications shipped to date (the VMware Linux product line) so I have a little background on the topic. I also happen to be an upstream GTK developer now since I left VMware 5 years ago.
And, quite frankly, this statement is incorrect. Plenty parts of GTK 2 were unstable during it's lifetime. In particular theming and gtkrc bits. I've written enough workarounds during the lifetime of gtk2 products to know. That is simply the reality when a piece of software tries to remain ABI stable for over a decade. It's really, really, really hard work (and as this post shows, almost completely thankless).
The only reason gtk2 is stable today, is because it's generally not touched (except for very specific bug fixes).
You'll see gtk3 be considered stable in the near future, but with a longer lifetime of bug fixes than gtk2 has gotten. Some of us are arguing for in 6 months, some for a year'ish. Meanwhile we will develop and stabilize gtk4 to land in the next series of long lifetime releases. We haven't hashed out all the details yet, but that could mean that if you subscribe to our 6 month release cycle, you might depend on say "gtk-4-unstable.pc". Where as, once we start on gtk 5, you can depend on "gtk-4.pc" and everything is guaranteed stable going forward. Those on the GTK release cycle will then consider moving to "gtk-5-unstable.pc".
By moving our major numbers sooner, it's very clear that the major version you are on is no longer game for major changes. I wish we had a butter way to deal with what we call the numbers (4.6 being 'stable' for example), but semantic versioning here isn't really sufficient (nor simply soname versioning alone).
We couldn't really come up with a better naming system than to say something like "4.6 is considered stable". This is a complex problem because we can either require everyone to bump their pkg-config dependencies again once they know they are stable, or not. We discussed doing something like 4 stable and 5 development, 6 stable, etc but ultimate decided against (as much as a half day decision can be) due to the churn it would take maintainers to update build system.s
This is mostly made more difficult because of distributions. They often deal with packages that are written and then stagnate for a couple of years and would like them to keep working (Debian Testing → Stable for example).
We've only discussed this for half of day-one of our current hackfest, so of course, if you have input, this would be a great time to join #gtk+ and make your voice heard. Many of us are here i...
I've written a Raleigh theme more than 12 years ago, and that one still works as it did back then.
I believe you when you say not all parts of Gtk2 were stable and some stuff was surely evolving, but the overall I've seen no regression in Gtk2 as I did in Gtk3.
That said, if Gtk3 has only been considered stable since 3.20, then more appropriate versioning/communication might have been useful, but I doubt that's what you're saying.
Also, I know I have too little domain knowledge to judge what it takes to support HiDPI and Wayland, but what I do object is focusing on too many things for a major release. What works better are time based releases where, if one feature branch misses the release, it'll arrive in a later version. Full rewrite efforts seldom work out.
You said Raleigh should work in 3.20, I just tried to use it as the 3.20 theme again and it's still borked compared to 3.18, but it's unsurprising if it's not the default and probably untested.
But what's more important is that Gtk2's Raleigh looks really nice, whereas 3.20's Raleigh looks like it's deliberately made to look worse, which is hard to understand, given that the drawing code is supposed to be 99% unchanged, if I look at Gtk2 to Gtk3 porting guides.
The theming API is what I was regarding as stable come 3.20. (CSS elements are finally documented, for example). And you are right, we could have done a better job of communicating it. It was obvious to those of us who work with GTK every day, (and theming has been unstable since gtk2 was released as it required C code), but it wasn't stated in large block print anywhere. We could have done better. To help with this we started, a few weeks ago, a new GTK blog to help people stay up to date. (blog.gtk.org)
> Also, I know I have too little domain knowledge to judge what it takes to support HiDPI and Wayland, but what do object is focusing on too many things for a major release. What works better are time based releases where, if one feature branch misses the time window, it'll arrive in a later point release. Full rewrite kinda efforts seldom work out.
Gtk3 has been large parts of rewrites done in short 6 month increments. That said, writing things like a full CSS 3 implementation that themers asked for is no small task. And making a modern toolkit that ships in 5 years does not do Free Software a service if it's too late to be useful. We've been trying to strike the right balance, but it takes developers testing things during the development cycle to really make that possible. Unfortunately, GNOME is pretty much the only project doing thate.
> Finally, I just tried to use Raleigh as the 3.20 theme again and it's still totally borked compared to 3.18, but it's unsurprising if it's not the default.
We should probably remove it from the list, to be honest. Adwaita "is the GTK theme", not Raleigh. I can add this to tomorrows topics at the hackfest.
> But what's more important is that Gtk2's Raleigh looks really nice, whereas 3.20's Raleigh looks like it's deliberately made to look worse, which is hard to understand, given that the drawing code is supposed to be 99% unchanged, if I look at Gtk2 to Gtk3 porting guides.
The drawing model of gtk2 and gtk3 are completely different. The themes are CSS now so the Raleigh theme, at minimum, has been ported from C code to CSS.
As a long time C and assembly hacker, I certainly know the feeling. However, with were we are going, we have evidence we can do faster on the GPU with various shaders than any of us can do with hand written assembler these days. I anticipate gtk 4.x rendering to vaguely look like webrender (which if you squint hard enough, looks similar to clutter 2.0 design).
> It's also how proper emulations of other operating systems' looks was achieved without an unresponsive set of bitmaps. The general purpose'ness of CSS will inevitably have limitations that either restrict what can be drawn or how efficient it can be made.
Our CSS engine does support SVG for scalability just fine with "bitmaps". The most difficult part of the current win32 theme work (partially landed in 3.20) is that we have lots of widgets that there is simply no analogous in win32. So making a "on|off" toggle look like win32 isn't exactly clear. I haven't tested the new theme on win32, but I do think a bunch of it is improved (note that running the win32 theme on Linux is not the same as running the win32 theme on win32, it requires some internal windows API for some of its features).
While true, the same shader can be written and incorporated in an engine written in C.
The most important feature is API stability so that good themes can be created. For example, some Gtk2 scrollbar settings like the arrow buttons seem to be gone in Gtk3. Is the idea that scrollbars should be drawn and callbacks implemented in JavaScript for arrow buttons?
> While true, the same shader can be written and incorporated in an engine written in C.
This is not true, unless you do all the same plumbing. We have two major pieces of evidence for this:
1) gtk-theme-engines from 2.x days almost universally caused crashes in applications when the did stuff wrong (and they all did)
2) You can't hide the details of the GPU pipeline behind a theme. it really changes the entire model of the application, how you store and cache state, how you pass it to the GPU, when you deliver that information, etc.
> The most important feature is API stability so that good themes can be created.
This is exactly why we want to have a stable release that wont be getting breaking changes. We think, practically, that most application developers will target the stable release (and therefore the stable themes). We think the primary users of unstable will be GNOME applications or other desktops that choose to align themselves with the GTK unstable cycle.
> For example, some Gtk2 scrollbar settings like the arrow buttons seem to be gone in Gtk3. Is the idea that scrollbars should be drawn and callbacks implemented in JavaScript for arrow buttons?
I'm not totally up to date on context here, bugzilla would be the best place to discuss this further.
We have bug reports coming especially from people using the Oxygen theme, which had a tendency to (against all recommendations) poke at the widget structure behind the style contexts because what could possibly go wrong.
Given the ability to inject random C code into applications that do not expect that, people will abuse it; hence the switch to a pure declarative language like CSS to describe the aspect of widgets. Your app may look like crap, but it won't crash because of that.
On one hand okay fine. On the other hand this is ass backwards: just admit you're doing beta releases.
Beta releases are done within the regular 6 month cycle.
The extraction of the toolkit from GIMP was done as the early pioneering of GNOME. Before that, it wasn't really a toolkit. I mean, it was an in-application toolkit, but that is very different from a usable toolkit.
I'm not sure why they couldn't use the benefit of being in control of the toolkit while developing GNOME, and write some adapter layer, like KDE.
The linked post is a rather confusingly written way of saying that Gtk 4.6 will have a stable ABI but that Gtk 4.0-4.5 won't (and thus shouldn't be used outside GNOME, if I understand it correctly).
But seriously, giving multiple years between the major versions is a lot of time in between for applications to port forward (or they can choose the version they want to stay on) and enough time to stabilize features that take more than 6 months to write. Turns out writing whole new rendering engines takes some time and testing and can't be flipped on as fast as javascript frameworks materialize.
If applications want to stay on a stable version for 5 years or more, that all of a sudden becomes tenable which wasn't the case before unless you wanted to stick to gtk2, which is right out of 1998 "how to write a toolkit".
This isn't very different from other systems that bump the soname and have multiple versions based on what ABI, as required by the applications. I'm sure you have multiple of these on your system already. The reason soname isn't enough for GTK has to do with parallel installability of headers, bindings, etc etc
The serious problem here is that, What this plan shows is a total lack of concern. Doing rolling release for a distribution is OK, but for a fundamental library this is unacceptable. Qt has been doing much better on this.
It really comes down to ensuring that developers are shipping a known quantity. They should be shipping with a set of libraries that were actually tested.
It's unreasonable to expect the toolkit authors to be able to test every possible permutation on every release unless people stand up to run build bots, automated testing, and report back to us when things break.
Keeping your Texmacs, for example, working in 5+ years time is important to us. That is why we want to give it a stable API that only gets bug fixes after a certain time frame. Is that such a bad idea? Would you really expect to magically get touch, HiDPI support, etc on a 5 year old application when you never changed your application code?
For a fundamental library like this devs should at least keep core api stable for a long time, and release unstable components seperately.
As I have stated, I really don't like a large number of similar libraries installed on my machine, each with a bunch of dependencies.
This is something we'd like to get to (say external widget libraries). But it requires, guess what, an ABI break :)
> As I have stated, I really don't like a large number of similar libraries installed on my machine, each with a bunch o dependencies.
This is a long running "problem" on GNU/Linux. I've been around for a couple of decades and the problem has existed pretty much the entire time. We all have some holy grail of design in how we'd like the world to be and are disappointed it isn't what we think it should clearly be.
I'm not saying your viewpoint isn't valid, just that I'm not sure you can put the necessity to solve it on our shoulders.
The controversial around this plan origins from people's inability to understand why such a fundamental library like gtk+ needs to have api break in such a high frequency, which would have a huge impact on the experience of app devs and users? The world has its intrinsic complications, but we all hope to avoid the casual one.
Yes, just a recompile in all the cases we've really discussed. However, if we can break ABI in minor releases, we have contemplated the idea of installing private headers to allow developers to "do wtf they want" with a I_KNOW_WHAT_IM_DOING #define or something.
But the important thing, is to test the software!
> The controversial around this plan origins from people's inability to understand why such a fundamental library like gtk+ needs to have api break for such a high frequency, which would have a huge impact on the experience of app devs and users? The world has its intrinsic complications, but we all hope to avoid the casual one.
That is the thing. We are a very small team of mostly part time contributors trying to build a toolkit that competes with the big players, who have teams the size of hundreds. There is a lot of work to do, with an insane cadence required.
I don't think this isn't really any different than choosing your target device version for say, iOS, Android, or macOS. They likely are likely breaking subtle things in-between major releases too, but you can either 1) lock to a version or 2) upgrade and fix-the-world.
Mandate the world to do test is not a good idea sine the philosophy of the world is to make it work.
>I don't think this isn't really any different than choosing your target device version for say, iOS, Android, or macOS.
No it's not. In case of device only a small bunch of things break. For gtk+ everything breaks without a fix.
That's because about every other year they have the equivalent of a major ABI break (and they you target explicitly the newer version or stay locked to the old version) and the platform ships both.
This is semantically what we will be providing.
Likely GTK would be house in the Gnome runtime, as afaik Flatpak has no concept of multiple runtime dependencies...
However, there is nothing stopping someone from creating another runtime (or even doing a gtk.org runtime) that is more conservative in nature.
And if you use a compiler toolchain that does reproducible builds, you'll still get all the deduplication magic from OSTree.
I don't think so, but GNOME does have a long history of diving down the stack and fixing problems when we run into them in lower levels. Of course, fixing long standing bugs that are often depended on corner-cases is certainly going to require additional engineering (the current tmux/screen situation comes to mind).
These things are largely a thankless task, and often a hostile process. Everyone seems to want their bug fixed, and nobody elses.
We very much need everyone interested in our shared commons to come to the table and discusses their needs. Otherwise it's not a commons.
And that may well be why we see a whole lot more controversy surrounding Gnome than KDE...
And after gtk4.xx is released, are bug fixes supposed to happen on the newly unstable gtk5? -- I'm so confused.
But that said, it's not that we don't have a plan. We have a very concrete plan in moving to a GL renderer, render trees, shader-based CSS drawing, and more. However, that necessarily means breaking the imperative drawing model that has us stuck in 1998.
So what are we to do?
Version numbers are just a thing. I think semantic versioning makes people put a little bit more confidence in what they are than its worth, but we did discuss this quite a bit.
We have a few options, some of which might be a "gtk-4-unstable.pc" pkg-config, or bumping soname more (but if we do that, why not bump the major number too), etc etc. We are all long term Free Software veterans maintaining long running ABI software projects. We are certainly thinking about the consequences of our choices from a developer, user, and distributor viewpoint.
Yes, and they should mean something. Not having a fixed API/ABI for an entire major version goes against what everyone else thinks that version numbers mean. You can talk yourself into thinking that the numbers don't matter - that only the semantic versioning (whatever that is) matters. But that doesn't mean that everyone else will agree, let alone understand what the hell you're talking about.
That said, if we can't guarantee the minor versions as we drain the swamp to rebuild this toolkit into something modern, we either need to not release anything (which makes it very hard to build if you can't get users to test things) or we need to come up with alternate versioning schemes.
Really, the reason why this strikes a chord is that it is confusing as hell. What is the rationale behind not allowing a 4.2 project to be built once 4.4 is installed on the system? That is the truly confusing part. Are you expecting that many backwards incompatible changes between 4.2 and 4.4? Why do the headers and packages need to share the same namespace?
I'm sure a lot of thought went into this, but something just doesn't seem right to me...
This certainly came up in our discussions... I think many people were left with a bad taste in their mouths due to trying to decode Linux version numbers. In my opinion, anything that has an actual decode algorithm would be better than the current situation of ... i dunno? :)
> Really, the reason why this strikes a chord is that it is confusing as hell. What is the rationale behind not allowing a 4.2 project to be built once 4.4 is installed on the system? That is the truly confusing part. Are you expecting that many backwards incompatible changes between 4.2 and 4.4? Why do the headers and packages need to share the same namespace?
I think this was miscommunication to be honest.
The installation headers for 4.0, 4.2, 4.4, etc will not be parallel installable based on the current idea. So when your distribution upgrades to 4.4, anything you compile against the -devel headers will be for 4.4. However, if they keep the previous soname version for 4.2, I don't see any reason that program couldn't keep working.
Of course, we could try to discover the ABI incompatabilities with libabigail, but history has shown us (over the last couple years) that there is a lot to ABI breakage that has nothing to do with symbols. Theming, expected behavior...
> I'm sure a lot of thought went into this, but something just doesn't seem right to me...
We certainly appreciate feedback. We are trying to be reponsive on irc.gimp.net #gtk+ during the hackfest, and your concerns will be relayed to the group. We are a fairly small group of about a dozen people, but gtk+ is important to us and we care about improving things.
I think the controversy is that, when I read this, I get the impression that GNOME devs either don't believe that backwards compatibility is possible in the long run, or that it's at least unpractical. I don't really get that impression given QT's backwards compatibility, MFC, etc, but if they really believe it, then faking it is unproductive, and just making a more distro-like release plan is reasonable.
I really can't get the distro comparison out of my head - it's like they tried a single release that lasted forever, and that didn't work, so they tried a rolling release, and that didn't work, so now they're going with unstable releases with LTS releases every 2 years.
The average developer does not think "oh, 4.2; that's an alpha release", they think it's two iterations on 4.0.
Thanks for sharing.
And they have the backing of RH in this, by way of Fedora and Freedesktop.
Lets not forget that Freedesktop was actually founded by Havoc Pennington while working at RH on desktop matters. Frankly Freedesktop do not exist to actually foster interoperability. it exists to whitewash RH decisions.
For me, Linux is better when there is a distinction between kernel, user space (and its various parts), X, and the DE/WM.
The direction things are going right now means tightening integration by using systemd as the glue, and Gnome as honey. All to lure distros in and get them stuck like flies on, well, flypaper.
This is ludicrous to anyone who has worked at Red Hat at some point in their career. Red Hat internally is almost a perfect mirror of the community at large. There are thousands of differentiating viewpoints on pretty much any topic related to Free Software (including if we should call it Free Software).
The group of people working on desktop at RH are quite small, it's not the cabal you seem to imply.
> All to lure distros in and get them stuck like flies on, well, flypaper.
We're trying to build a modern operating system where the components are part of a whole. I'm sorry you feel that is some sort of trap. That is not the intention, in any way.
If you're shipping binary packages, you need to build them in a clean chrooted environment anyway (such as pbuilder/sbuilder/docker or a VM) or you're going to end up with binaries that depend on the latest glibc point release that happens to be installed on your system.
glibc doesn't break API dramatically with each new version ... Gtk does and that's an insane burden put on developers using that thing. You can't develop stable tools with an ecosystem that keeps on breaking. Why should I bother with Gtk when I can learn a more stable GUI framework ? that's right, and I don't. Then the Gnome Foundation complains people aren't using Gtk ... I see a lot of Gnome projects started then abandoned, only to see a new project doing exactly the same thing being built from scratch afterwards. For instance, they are working on a new IDE Gnome builder, who the hell needs this when multiple projects like Gedit get very little contribution today ? To me the Gnome foundation is wasting money with all that stuff, while investing very little in the documentation for instance. Their website is a mess.
"They" → me
Like seriously, me. It's not the GNOME foundation. They've given me no money. I do get occasionally contributions from the same people that build Gedit. I also spent most of a decade contributing to another well known IDE for Mono. So this isn't my first rodeo.
A significantly amount of work I've done on Builder HAS flowed upstream into both GTK and Gedit, so clearly you have no clue what you're talking about.
> To me the Gnome foundation is wasting money with all that stuff, while investing very little in the documentation for instance. Their website is a mess.
Again, your money to the foundation has never gone to Builder, but I also hope to have a large demo regarding documentation to show at GUADEC, should you choose to attend.