8 ms·

GNOME's plan to discourage portable Gtk apps

43 points by cm3 10y ago

cm3 10y ago
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).
- PeCaN 10y ago
  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.
  - audidude 10y ago
    It turns out if you want modern features you pretty much have to change everything that was done in the drawing model in gtk2.
  - digi_owl 10y ago
    Because there is no need. GTK3 is basically a fork of GTK at this point. Just grab GTK2 and go. 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?
    - deleted 10y ago
      [deleted]
    - audidude 10y ago
      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).
- audidude 10y ago
  > 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 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.
- ChuckMcM 10y ago
  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.
  - digi_owl 10y ago
    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).
  - cm3 10y ago
    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).
Avshalom 10y ago
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.
- megous 10y ago
  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.
  - digi_owl 10y ago
    Then they should just fork GTK and be done with it. Or write a layer between GTK and Gnome, like there appears to be between KDE and Qt.
    - audidude 10y ago
      If GNOME forked GTK, there would no longer be a GTK.
      - digi_owl 10y ago
        I could have sworn GTK existed before Gnome. Surely it can exist after as well...
        audidude 10y ago
        You are likely miss-remembering. 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.
    - megous 10y ago
      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.
DeepYogurt 10y ago
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.
- elktea 10y ago
  Yes. or GTK4-alpha-1 to 5 before that big 4.0 point release.
  - audidude 10y ago
    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.
SwellJoe 10y ago
Editorializing in the title is discouraged.
- cm3 10y ago
  Suggestions welcome. I tried to title it more descriptively than the original LWN or blog subjects, but it seems I failed. Sorry.
  - swhipple 10y ago
    "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.
    - cm3 10y ago
      Thanks. Your suggestion sounds correct to me.
amluto 10y ago
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).
stshine 10y ago
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.
- audidude 10y ago
  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
  - stshine 10y ago
    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.
    - audidude 10y ago
      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?
sorpaas 10y ago
Not a problem for NixOS!
- digi_owl 10y ago
  Bingo. This seems tailor made for the also "Gnome" developed flatpak scheme...
  - cm3 10y ago
    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.
    - digi_owl 10y ago
      Their idea is for apps to depend on runtimes that in turn can exist in multiple versions. Likely GTK would be house in the Gnome runtime, as afaik Flatpak has no concept of multiple runtime dependencies...
      - audidude 10y ago
        GNOME's runtime will certainly ship an up to date GTK. 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.
        cm3 10y ago
        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.
mjs7231 10y ago
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.
- audidude 10y ago
  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.
  - mbreese 10y ago
    Version numbers are just a thing 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.
    - audidude 10y ago
      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.
coroutines 10y ago
Does anybody have any confidence in GTK over Qt at this point?..
- db0451 10y ago
  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++.
jprzybyl 10y ago
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.
- deathanatos 10y ago
  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.
  - audidude 10y ago
    This is a completely valid viewpoint, and one we can discuss tomorrow at the hackfest. Thanks for sharing.
  - rakoo 10y ago
    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.
dlitz 10y ago
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.
- spriggan3 10y ago
  > 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.
  - audidude 10y ago
    > 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.
tomjen3 10y ago
Pointless. Just add docker or vagrant or even chroot as a build step and be done with it.

43 points by cm3 10y ago

cm3 10y ago

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

PeCaN 10y ago
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.
- audidude 10y ago
  It turns out if you want modern features you pretty much have to change everything that was done in the drawing model in gtk2.
- digi_owl 10y ago
  Because there is no need. GTK3 is basically a fork of GTK at this point. Just grab GTK2 and go. 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?
  - deleted 10y ago
    [deleted]
  - audidude 10y ago
    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).
audidude 10y ago
> 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 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.
ChuckMcM 10y ago
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.
- digi_owl 10y ago
  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).
- cm3 10y ago
  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).

Avshalom 10y ago

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.

megous 10y ago
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.
- digi_owl 10y ago
  Then they should just fork GTK and be done with it. Or write a layer between GTK and Gnome, like there appears to be between KDE and Qt.
  - audidude 10y ago
    If GNOME forked GTK, there would no longer be a GTK.
    - digi_owl 10y ago
      I could have sworn GTK existed before Gnome. Surely it can exist after as well...
      - audidude 10y ago
        You are likely miss-remembering. 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.
  - megous 10y ago
    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.

DeepYogurt 10y ago

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.

elktea 10y ago
Yes. or GTK4-alpha-1 to 5 before that big 4.0 point release.
- audidude 10y ago
  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.

SwellJoe 10y ago

Editorializing in the title is discouraged.

cm3 10y ago
Suggestions welcome. I tried to title it more descriptively than the original LWN or blog subjects, but it seems I failed. Sorry.
- swhipple 10y ago
  "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.
  - cm3 10y ago
    Thanks. Your suggestion sounds correct to me.

amluto 10y ago

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

stshine 10y ago

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.

audidude 10y ago
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
- stshine 10y ago
  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.
  - audidude 10y ago
    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?

sorpaas 10y ago

Not a problem for NixOS!

digi_owl 10y ago
Bingo. This seems tailor made for the also "Gnome" developed flatpak scheme...
- cm3 10y ago
  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.
  - digi_owl 10y ago
    Their idea is for apps to depend on runtimes that in turn can exist in multiple versions. Likely GTK would be house in the Gnome runtime, as afaik Flatpak has no concept of multiple runtime dependencies...
    - audidude 10y ago
      GNOME's runtime will certainly ship an up to date GTK. 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.
      - cm3 10y ago
        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.

mjs7231 10y ago

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.

audidude 10y ago
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.
- mbreese 10y ago
  Version numbers are just a thing 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.
  - audidude 10y ago
    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.

coroutines 10y ago

Does anybody have any confidence in GTK over Qt at this point?..

db0451 10y ago
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++.

jprzybyl 10y ago

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.

deathanatos 10y ago
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.
- audidude 10y ago
  This is a completely valid viewpoint, and one we can discuss tomorrow at the hackfest. Thanks for sharing.
- rakoo 10y ago
  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.

dlitz 10y ago

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.

spriggan3 10y ago
> 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.
- audidude 10y ago
  > 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.

tomjen3 10y ago

Pointless. Just add docker or vagrant or even chroot as a build step and be done with it.