And the second part of the essay (the juicy part, too):
Inspiration, isolation and alienation: GTK+ 3.10 to GTK+ 3.14
With almost nobody actually using GTK+ 3 other than GNOME, the GTK+ /
GNOME developers realized they were alienated. At first, after releasing
GTK+ 3.0.0 they patiently waited for anybody to dare port their software.
Almost nobody dared. Mozilla was working on the GTK+ 3 backend early on,
but failed to officially support GTK+ 3 in their prebuilt versions. The
reason? Mozilla knew that many Linux systems (by this time other
UNIX-like operating system users were in the minority) lacked an installed
version of GTK+ 3, or at least they were not comfortable releasing a GTK+
3 version of their applications before GTK+ 2 desktops started to disappear.
By 2015 Mozilla had started releasing GTK+ 3-based versions of their
applications.
Ubuntu's Unity desktop environment also ported to GTK+ 3 fairly early on.
Though initially it used GTK+ 2, certainly by 2012 it required GTK+ 3.
But Unity was not much of an endorsement: Some people believed it was
better than GNOME 3, sure. But many others believed it was nothing more
than GNOME 3 in disguise. With developers so slowly coming out with
GTK+ 3 versions of their applications, it seemed like nobody would ever
port to GTK+ 3. Years before, when GTK+ 2 was still relatively new,
only a minority of applications still used GTK+ 1 -- most were ported
quickly to GTK+ 2. Yet by this time application developers were dragging
their feet because they felt duped by the excitement surrounding GTK+ 3 --
and they saw what was coming after that disappointing release.
By 2013, the GNOME team hardly saw any reason to keep very much of the
interface traditional, since only GNOME and a few other software packages
used it yet -- the truly big names such as the GIMP, Inkscape and VMWare
were yet to come. Because of this sticky situation, they decided to add
and remove features as they saw fit without asking the rest of the
community first. (Notification is one thing; participation in the
decision-making process is another completely different matter.) One of
the first products of their GNOME-ization was the header bar, a widget
which remotely resembled a window title bar but was taller and had enough
space to include other widgets. It also replaced the ordinary title bar,
replicating the Close button and other window controls on the side of the
widget. Sometimes, especially in dialogs, the Close button would not
even be present, and the buttons that used to be at the bottom of the
dialog would be moved to the top of the header bar instead. This worked
well for touchscreen users -- larger onscreen elements make it easier to
tap on the correct one -- but was disfavorable to everyone else, who was
used to mouse muscle memory.
Furthermore, several settings and even entire objects and widgets were
deprecated in subsequent versions. One of these was the GtkStatusIcon,
which could be used to display an icon in the status bar provided by
most operating systems. It was removed in version 3.14 without published
grounds. Also in version 3.10, a setting to alter the size of icons in
buttons, menu items, and the like was removed, and unconfigurable values
were hard-coded into GTK+. This may not have been such a bad thing, but
the GTK+ developers chose to use microscopic icon sizes for buttons and
menus, which led to complaints from people who are marginally visually
impaired but they don't like to wear glasses all the time. Over half a
dozen settings were deprecated and promptly ignored by GTK+ 3.10, including
gtk-auto-mnemonics, gtk-button-images, gtk-can-change-accels,
gtk-color-palette, gtk-color-scheme, gtk-enable-mnemonics, and
gtk-menu-images. Respectively, these settings were formerly used for:
-
gtk-auto-mnemonics: Whether keyboard shortcut mnemonics should be
automatically underlined when the user presses the shortcut key,
typically Alt. -
gtk-button-images: Whether images should be shown on buttons. -
gtk-can-change-accels: Whether the user can edit the keyboard
shortcut for a menu item simply by typing the new shortcut while
the mouse pointer is hovering over the menu item. -
gtk-color-palette: The set of colors shown by default in the color
selector. Note that the more modern color selector does not use this
property. -
gtk-color-scheme: The set of colors used by the theme. Used to
produce color variants of a theme. This option was actually removed
in version 3.8. -
gtk-enable-mnemonics: Whether keyboard shortcut mnemonics should
be underlined at all times. -
gtk-menu-images: Whether images should be shown on menu items.
The sudden contention for only the GNOME developers themselves was not
only quixotic, it served to further distance GTK+ 3 from other projects!
If the GNOME developers believed it was only rightful that they optimize
the GTK+ for themselves, then why should anybody else get on board with
GTK+ 3?
Red Hat turns the tables: GTK+ 3.16 through GTK+ 3.20
So, if GTK+ 3 flopped, how are we where we are today, with GTK+ 3 suddenly
being forced down our throats? It turns out it was probably started by
Red Hat. By 2015, Red Hat was already indicating that it was planning on
removing GTK+ 2 from its repositories and, by extension, its technical
support repertoire. So Red Hat basically said that they would no longer
offer companies who paid for technical support any support for GTK+ 2.
Needless to say, this started a panic. Many developers realized that they
needed to get their act in gear and port to GTK+ 3 if they wanted to be
taken seriously. This was about the time that Inkscape and VMWare ported
to GTK+ 3. It was also when Mozilla began offering official builds of
their applications built with GTK+ 3. A large enough corporate entity
can control all of us if it wants to.
But some projects remained stubborn. Most notably, the GIMP did not
produce a GTK+ 3 version; they were fairly anti-GTK+ 3 even from the
very start. Even today, the GIMP still has not provided a stable
release built with GTK+ 3, although work progresses on a port as we
speak.
GTK+ 3 continued to develop into a more and more touchscreen-friendly
interface, mandating more and more rules from the GNOME Human Interface
Guidelines on all GTK+ 3 applications. One of the watershed moments of
GTK+ 3 was when the scrolling system was redesigned. Though it meant
that touchscreen (and later touchpad) users could scroll up and down
a page of text smoothly (a mechanism known as "kinetic scrolling"), many
other aspects of the scrolling system were inadvertently broken. For
one, the scrollbar steppers ceased to scroll by reasonable amounts at
a time; they only scrolled by single pixels at a time, though this change
was likely unnoticed because Adwaita, the default GTK+ theme by this time,
did not display any scrollbar steppers. Initially, when any part of the
scrollbar was clicked on, the slider would immediately jump to that
exact location on the page; this change was later reverted (actually, a
setting was instead put in place) when a protest by the community
threatened to become a virtual riot. And the scrolling behavior brought
with it the unfortunate truth that scrolling became painfully slow on
older hardware.
The death of GTK+ 2 and the conception of GTK+ 4: GTK+ 3.22 & 3.24
By 2016, already there was discussion about what GTK+ 4 would bring.
Very early on, it was realized even by the GTK+ developers that GTK+ 3
was kind of slow. Hence, to counteract the sluggishness of GTK+ 3,
version 4 would take more advantage of the graphics hardware in the
host computer -- while leaving old graphics hardware behind. The plans
were drawn up and GTK+ 4 development began.
At some point, a GTK+ developer realized that the plus sign on the GTK+
name was too hard to type, so the historic decision was finally made to
drop the plus sign from a later development version of GTK+ 4. Hence
GTK 4 is the new name for the up-and-coming graphical toolkit.
At about the same time GTK+ 4 was announced, a new version of GTK+ 3 came
out: GTK+ 3.22. This was staged to be the last version of GTK+ 3. In
reality, like in 2011 with GTK+ 2.24, GTK 4 needed more time to mature
and thus GTK+ 3.24 was released eventually.
It's also important to note that GTK+ 2 is not alive and well anymore.
In 2018, the last release of GTK+ 2 was produced: GTK+ 2.24.32. It was
announced that GTK+ 2 would never be released again. By 2020, the present
year as I write this, some distributions had actually, finally, started
dropping GTK+ 2 from their repositories. Fedora, being Red Hat-sponsored,
was one of the first to do so. Finally, GTK+ 2 had been beaten in an
18-year-long battle.
What does this all mean for the future?
First of all, I am proud of you if you managed to get all the way to here
without passing out first. That was a lot of material about history, and
I could forgive you if you didn't read everything. That said, I'll be
using history as my prediction system, so if you don't understand
something that I'm saying, just look back up at the history list.
That said, I think we should look at where GTK 4 will be in a few years
from now, perhaps around version 4.10. As I already said, a lot changed
in GTK+ 2 from its beginning until its end, and a lot has changed with
GTK+ 3 from the time of GTK+ 3.0.0 through the time of 3.14. As I already
mentioned, GTK+ 3.0.0 was actually still pretty conservative; it took
until version 3.8 or so before things really started going haywire, so to
speak.
Taking GTK+ 3 as an example, I think many features of GTK 4 that were not
removed initially, such as the toolbars (albeit in a crude form now) and
the menu bars (excuse me -- popover menu bars), will be deprecated by
GTK 4.10 or whereabouts. Sure, when a feature is deprecated, it is not
removed immediately; you can theoretically continue using the feature.
But when GTK 5 comes out, the feature is gone for good (at least from GTK
5). Plus, some deprecated features of GTK+ 3 no longer work anyway: All
of the settings which I quoted above as being "removed" were just
deprecated, but they have effectively been removed because GTK+ will not
react to any value set in any of those settings. Furthermore, take a look
at this deprecated style property for menu items with a checkbox next to
them: The indicator-size property for years would contain the actual
width of the checkbox itself in pixels. A typical value was 16, but the
value for my GTK+ 3 theme that I'm using right now (TraditionalOk) is 14.
Now, why does this matter? Well, Mozilla applications rely on the value
of this property to know how large to draw the checkbox in the menu.
Prior to GTK+ 3.20, this indicator-size property had a meaningful
value. By GTK+ 3.20, the property had been deprecated and no longer was
a source of useful information; it always reflected that the checkbox
width was 16 pixels, even if it was actually 14! Why does this all make
any difference, besides having slightly big checkboxes? Well, the theme
I'm using does not use vector graphics very much; the checkbox image is
a standard, unscalable raster image, so if a Mozilla application is duped
into drawing this indicator 16 pixels wide (which they are duped), then
the indicator is scaled up and looks fuzzy, and the result is I can't
always tell what state a checkbox is in anymore. That's the significance.
Come to think of it, deprecating and then immediately (intentionally)
breaking a feature is thoughtless. There is almost no point to
deprecating the feature as opposed to simply eliminating it. But I
digress.
So my thought is that the (already meager) toolbar and popover menu
support that we do have will probably be broken in some way by GTK+ 4.10.
It's really not hard to imagine that -- as I already mentioned in my
previous article, even the GTK 4 demo application does not use the new
"toolbar style class". And the error actually appeared in two demo
applications, not just one. It's not hard to add the style class to the
applications; at most it's three lines of code added to each application.
Futhermore, we are heading into an era of changes being made without
formal announcements of any kind. Think of the scrollbar steppers having
gone missing without any obvious documentation about that. In fact, the
documentation even misleadingly still documents the steppers. On the
other hand, maybe it will get documented when GTK 4.0.0 actually comes
out later this year, perhaps September 25th or whereabouts.
Now you may be thinking, "Well, we've got years to go on this issue; why
are you so worried about GTK 4 as of yet?" Well, by the time GTK 4.0.0
actually does come out, the latest version of GTK+ 3 will probably be
3.24.23. As for the significance of that version number, few versions of
GTK have ever had a micro version number that high. (The micro version
of a release is the rightmost of the three digits in the version number.)
GTK+ 2.24 wound up reaching micro version 32, but that was a very special
exception; previously it was rare to go above 15. And unlike GTK+ 2.24,
GTK+ 3.24 was not released almost in tandem with GTK 4.0.0; in fact, the
first release of GTK+ 3.24 was in early 2019, by now a year and a half
ago. Furthermore, GTK+ 3.24 has not been getting very many bug fixes or
changes applied to it lately; each release brings relatively minor
changes, even by micro version standards. And last but not least, I think
GTK 4 is roughly what the GTK team wanted GTK+ 3 to be like all along.
So no, I do not think that GTK+ 3 will continue much longer.
And you may now be thinking, "Maintenance schmaintenance! Who cares if
it's actively maintained?" But if you're asking this question, I direct
you to immediately try to compile GTK+ 3.0.0 on a modern operating system.
Chances are the compilation process will not work. It's because GTK+
3.0.0 depends on a feature in GDK-PixBuf (basically, the GTK image
handling library) which was not deprecated back in 2011 but is deprecated
now. To use the feature now requires a little extra code to ensure some
deprecated features are enabled. So point number 1 is that the code you
save up today may not work for you in a few years. (I tend to think of
software as being like money, and the progress of software development as
being inflation. In such a system, software is okay to use as long as
you don't attempt to hold onto it; if you do, it decreases in value until
it eventually becomes nearly worthless.)
The other problem with unmaintained software is that you basically are
committing yourself to putting up with the same bugs in the same software
for years to come -- without any likelihood that the bugs will be ironed
out in the next release, or the release after that. I have far too much
experience with this issue, and thus I have a slight sour taste in my
mouth about doing it all over again. You wouldn't have guessed how
infuriating GNOME 2 could be if you had to put up with the same bugs
over and over again... So point number 2 is that the software may drive
you nuts over time and you might be another reluctant adopter of GTK 4
eventually.
And as for the future concerning Wayland: I suspect the GNOME developers
are frustrated that X is still used today despite it being more than 35
years old. Very obviously, GNOME has launched a campaign to make the
GNOME experience better on Wayland than on X. (I've used the most modern
versions of GNOME to an extent. The Wayland version is much faster and
generally smoother than the version for X.) GTK 4 is not as smooth
sailing on X as it is on Wayland; there are numerous flaws, and based on
how GNOME bug reports have gone in the past, either the developers are
interested in patching the flaw or they're not. And if they're not, then
the bug report will stay open until the bug is not an issue -- perhaps
because by then they've decided the X backend is buggy enough -- sorry,
I mean too buggy -- that nobody uses it anymore and they therefore have
no need to continue "maintaining" it. I suspect by GTK 4.16 (if it ever
gets to that high a version number) that the X backend will be deprecated
or even removed already, and almost certainly will be removed by GTK 5.
Think of when support for Mir (Ubuntu's windowing system similar to
Wayland) was dropped in 2019 -- that was not in a major release, that was
in the (relatively) minor release of GTK+ 3.24. Sure, almost nobody
still used Mir, since it went out of vogue when Ubuntu dropped their own
Unity desktop years earlier; but my prediction is that like Mir, X will
also become obsolete by 2030 or whereabouts, at least to the GNOME
community who only need to run GNOME applications.
In conclusion
I envision a time from now, maybe around 2030, when GTK 4 has all
non-GNOME-centric features deprecated and GTK 5 is the final major version
of GTK. At that point, the only thing to maintain in GTK 5 is bug fixes,
platform changes, et cetera, not any feature changes. I have reason to
believe that by 2030, GTK will have so few users left (because everyone
else has deserted for Qt or something) that the only users it will have
left are those who actually use GNOME. My ultimate prediction is that
within about three years after GTK 5 is released, touchscreens will go
out of vogue and GTK and GNOME will collapse. At that point, anyone left
in the sinking boat will be astonished that such a great piece of software
could meet such a terrible end. In the end though, the rest of us will
realize that software -- and any product for that matter -- is not great
because of its history:
Software is great because of its content and, ultimately, because of
its management.
Suppose you have a company with a good reputation. All that your
customers can think of is how great the company is. Then you sell your
company off to an apparently well-intentioned investor, and it turns out
that the investor is only interested in reaping the profits from the
company and turns the company into a disaster. This is not a good
company anymore; it was a good company, but your nostalgia is not going
to buy you anything, not even one of their products. And it certainly is
not going to buy you anything when the company files for bankruptcy due
to mismanagement. A company is defined by who the people are -- not by
who the people were -- at least in the modern world.
Thank you. You have now made it to the end of the article. Congratulations!
I'm very surprised anybody managed to read this thing the whole way through. It's over 44,000 characters of run-on diatribe about GTK.