GNOME's plan to discourage portable Gtk apps
lwn.net
lwn.net
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.
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).
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 in Toronto in person, but we are certainly still all on IRC listening to users there.
> 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.
If only we thought of it!
Sorry for the snark, but your comment really trivializes the amount of work it goes into such features. It is really hard to have a reasonable discussion unless you are willing to sit down and look over the last 5 years of development and how each incremental feature plays a part in building a modern toolkit.
We want to do much more modern things (like GL/vulkan rendering for example), and the recent half-decade has shown that is pretty much impossible for us to do without applications willing to test how well things work. That results in the natural feedback loop of improving things. Now, having both developers that want to write code and largely ignore it for 5-10 years is a different set of developers than those that are willing to stay up to date with the toolkit and test features as we add them. They are both completely valid desires of developers. We are stuck trying to satisfy both, which was not obvious when we started. When GTK3 started we thought it was going to be a "break everything while we figure out what GTK 4 will look like". As you can imagine (especially with hindsight), easier said than done.
Each incremental change that has happened from 3.0 to 3.20 is monumental in turning a toolkit that was state of the art for 1998 into a toolkit that is state of the art for 2016. I'm not going to rehash the gigantic list of all those features, as people have done that elsewhere already today. We still aren't where we want to go, but each change we've introduced has been a step in the progression to get there.
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).
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.
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.
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.
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...