
GNOME's plan to discourage portable Gtk apps - cm3
https://lwn.net/Articles/691131
======
jprzybyl
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
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.

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

~~~
audidude
I was very much pushing for a single version number, but there was some
hesitation to it. I'll try again when we discuss it next.

------
Avshalom
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
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
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
If GNOME forked GTK, there would no longer be a GTK.

~~~
digi_owl
I could have sworn GTK existed before Gnome. Surely it can exist after as
well...

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

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

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

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

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

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

------
DeepYogurt
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
Yes. or GTK4-alpha-1 to 5 before that big 4.0 point release.

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

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

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

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

~~~
stshine
> But the important thing, is to test the software!

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.

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

------
SwellJoe
Editorializing in the title is discouraged.

~~~
cm3
Suggestions welcome. I tried to title it more descriptively than the original
LWN or blog subjects, but it seems I failed. Sorry.

~~~
swhipple
"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
Thanks. Your suggestion sounds correct to me.

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

~~~
db0451
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++.

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

------
sorpaas
Not a problem for NixOS!

~~~
digi_owl
Bingo. This seems tailor made for the also "Gnome" developed flatpak scheme...

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

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

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

And that may well be why we see a whole lot more controversy surrounding Gnome
than KDE...

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

