Is there any future for the GTK-based Desktop Environments?

After many explorations, hesitations and tribulations; and after having thought that an Arch derivative with KDE is the way; and after having later considered that more desktop stability would be advisable, and having a fling for Ubuntu MATE 21.04, a quick experiment showed me that Ubuntu MATE cannot be trusted, and that maybe I should explore a little more in XFCE’s land. But as I was courting MATE, I learned more about the latest developments in GTK, and I became a bit worried. Is the Linux desktop heading south?

The good old GTK+ and XFCE

When I first met GTK, it was called GTK+, and it was at version 1.0 if not even worse. People at the time were using (under XFree86) FLTK, Tcl/Tk, Tkinter, gtkmm, PyGTK, wxWindows, FOX Toolkit. For GTK-based desktop environments, I’m not sure I used GNOME prior to version 2.4, nor XFCE older than 4.0. Older versions of XFCE were using GTK+ 1, which was ugly.

Qt3, then especially Qt4, were offering much more to the developer than a GUI library, but GTK+ was lighter, simpler, and friendlier to plain C developers, or to the developers of simpler languages such as Tcl. I was never a big fan of KDE, and when I started to accept it (say, KDE 3.3), its days were numbered: KDE4 introduced Plasma, the horrendous plasmoids and other stupid design concepts, plenty of crashes, and it was heavyweight. That KDE Plasma 5 is finally usable and stable, after having decided to stop pushing the ridiculous plasmoids on the user (were they liking the Windows Desktop Gadgets, or they were simply idiots?), is like having an old whore finally becoming a respectable woman. It’s hard to forget the developers’ idiotic decisions, though. I don’t like to be Microsoft’s guinea pig, why should I be KDE’s?

GTK+2 was fine the way it was. Conservative, rather minimalistic, but fine. Then GTK+3 came in, with two major issues: it wasn’t backward-compatible (nothing new in GTK-land), and it adopted the Client-side decoration (CSD) ideas.

You can read more about CSD in this older post, in the section “MY DESKTOP WAS IN THE LOUIS-PHILIPPE STYLE AND SIZE”; better search in the page for mimic gnome.

As GTK+ more or less belongs to GNOME, it’s no wonder GNOME3 was based on GTK+3. It’s from GNOME that the CSD-mania has contaminated the other projects.

Surprisingly, the MATE continuation of GNOME2 managed to transition to GTK+3 smoother than XFCE. MATE got fully GTK+3 in version 1.18 (March 2017), but for the end-user the process was invisible, without many hiccups. But XFCE was thought dead at least twice, between versions 4.10 and 4.12 (two years and 10 months), and between 4.12 and 4.14 (4 years and 5 months!). At least, XFCE 4.14 (August 2019) was finally using GTK+3, but the transition was fully completed only in XFCE 4.16 (Dec. 2020).

XFCE’s developers seem a bunch of nice guys judging by the 2017 interview given by Sean Davis to Dedoimedo (Igor Ljubuncic):

D: If you had unlimited budget to develop or enhance Xfce, what would you do?

S: Hire some development, design, and bug triage talent to knock out some long-standing issues and freshen up the ecosystem. We have some really high quality software, but it’s marred by some long-standing issues and design inconsistencies. Our small team consists of a number of talented folks, but working for free usually means that Xfce takes a back seat to life, and the list of TODOs and FIXMEs seems to keep growing.

D: Do you guys cooperate with other DE teams?

S: Olivier Fourdan, creator of the Xfce desktop and maintainer of the Xfwm window manager works for Red Hat and contributes to the development of Wayland, GTK+, Mutter, and GNOME Control Center. Simon (ochosi) maintains the elementary-xfce icon theme, where we inherit, adapt and finally contribute to elementary’s icon theme. Xfce depends on GTK+, so we submit bug reports (and the occasional patch) when things are not working as expected or documented.

D: What can the Linux community do together to make Linux, well, better?

S: Stop reinventing the wheel for the sake of being different. Review and accept patches, or offer suggestions to improve the patches. Check out new releases of different desktop environments, or even Windows and Mac OS to see if there’s new innovations you haven’t considered before. Finally, improved upstream and downstream cooperation would lead to a better experience for developers, maintainers, and users.

I have to admit I didn’t like the part about Olivier Fourdan working for Red Hat. Wayland, the changes in GTK+, GNOME… I mean, GNOME, the project Introducing the CSD Initiative (“tl;dr: Let’s get rid of title bars. Join the revolution!“).

Beyond the CSD issue, GTK+3 got several projects mad to the point of migrating to Qt (LXDE became LXQt; PCManFM started a Qt port from version zero, yet the GTK+2, GTK+3 and Qt versions coexist; Audacious switched to GTK+3, then back to GTK+2, then to Qt).

Strangely enough, decades ago I liked Qt’s themes. These days, I don’t. I still cannot use GNOME3/GNOME4 because of the stupid ergonomics (1. It seems designed for tablets. 2. The oversimplification killed it. 3. Removing the Compact List view in Nautilus made it unusable.). And I don’t agree to many of Cinnamon’s design options either. So what’s left in the GTK-land? XFCE and MATE.

As I wrote in the preamble, I had a disagreement with the MATE sheeple, so when I look at the GTK3-based XFCE, what I see is this:

• XFCE takes about as much RAM as MATE.
• XFCE takes almost as much RAM as KDE Plasma 5.

Thank you, GTK+3! You just destroyed XFCE’s legendary lightness! At least, it seems it’s still a better choice for battery life.

The crappy new GTK+ and… God help us!

If GTK+3 was already questionable and criticized, GTK4 (the “+” has been dropped in February 2019) has all the ingredients of a catastrophic upgrade for all the projects willing of needing to use it. Here’s what I learned while browsing Ubuntu MATE’s forums.

First, let’s mention the attempts to “fix” GTK+3:

• STLWRT: The traditional brought back to life. I don’t know anything about this GTK+2 fork, but it’s here.
• gtk3-classic (previously known as gtk3-mushrooms): patches to provide a more traditional experience to GTK+3 apps. I have tried it in some Arch derivatives, and it worked perfectly (compare Pamac before and after).
• libxfce4ui-nocsd: a fork of libxfce4ui to disable CSD and implement all new CSD-specific functionality as wrappers so that applications built against the new lib can continue to function. I have tested it in XFCE 4.16 and it just works. Note that in theory, this lib is part of a fork called Xfce Classic.

👉 From the above STLWRT announcement, by Gordon Squash:

I used to use GTK+ 1. GTK+ 1 was good enough for me at the time. At the time XFCE did not use GTK; it used XForms, a proprietary toolkit, which I did not approve of.

Then I switched to GTK+ 2. I found it was great. I used GNOME and LXDE desktops for a long time. (I got used to using GNOME, so I didn’t bother trying out XFCE for a long time, even once it was ported to GTK.)

Then came GTK+ 3. I realized something bad was brewing, even though it didn’t unfold as quickly as I figured it would. Soon after GTK+ 3 was released, GNOME 3 was released. This was when I dropped GNOME like a hot potato and have barely used it since then.

Fast forward some years and LXDE went dead. This was in 2016. I considered MATE and XFCE as my next desktops. I was hoping to go with XFCE but realized it was on the cusp of going partially GNOME-style, so I ultimately switched to MATE, the desktop I still use today. I thought I could live in peace forever.

I write apps with GTK. I am familiar with how GTK works, and I try to keep up-to-date on the latest information about the versions of GTK around the corner. I was thus disturbed when I read about what’s going on in the development of GTK 4. Many of the changes in GTK 4 seem, frankly, stupid to me and totally undermine the traditional GUI concepts. GTK 4 doesn’t even have real menus.

In the 9 years since GTK+ 3 was released, I’ve realized there are a lot of people who don’t like GTK+ 3 (and much less GTK 4), but who are unable or unwilling to do anything about it.

Today, there are still some “stubborn” developers who insist on keeping their applications GTK+ 2-only. Until recently the GIMP was like this.

On the other side of the coin, there are a lot of application developers who have just converted their applications to use GTK+ 3 and don’t want to go back. XFCE may be a good example of this.

And there are some projects which have been dropped over this insanity. LXDE is a good example of this.

…

As such, I have been working on a solution: STLWRT started as a fork of GTK+ 2.

👉 From the long thread GTK3 regressions from a GTK2 perspective, I’ve learned of gtk3-classic, but there is also this fucking idiot:

GTK2 was great, GTK3 is better in many aspects, but they dropped things that not enough software used and that there were not enough people to maintain… GTK4 will be a continuation of that: better, but more specialized libraries for GNOME’s use cases.

Forking GTK*, and/or forward-porting parts from “the good old days” sounds great in theory, but who’s going to do it? Who’s going to maintain it?

Off the top of my head, the MATE team is growing at a rate of, what, 1 developer a year? All volunteers too.

GNOME (and thus GTK) have hundreds of developers, many of which are paid to work on it. To expect them to stop and wait for us is unreasonable when we’re the ones that chose this path.

I think what we’re doing is fine: we backport what makes sense from GNOME, we add our own features every now and then, and we make wishlists to keep moving us forward. It works. We have an amazing desktop environment that makes us proud and happy. Some features will suffer with every upgrade, but we add other necessary ones too.

In the end, we do the best we can to keep things balanced between “traditional” and “modern”. That’s probably one of the hardest things to pull off, and yet that’s where MATE really shines.

Change for the sake of the change! “Better” but with fewer features, just like the retarded GNOME! And Red Hat, the main sponsor of this apocalypse!

Now, let’s talk of GTK4.

👉 From the long thread Horrible GTK3 / GNOME UI design is leaking into Ubuntu Mate applications in 20.04, the second post quotes from a link that’s now different (correct link):

GtkMenu, GtkMenuBar and GtkMenuItem are gone

These widgets were heavily relying on X11-centric concepts such as override-redirect windows and grabs, and were hard to adjust to other windowing systems.

Menus can already be replaced using GtkPopoverMenu in GTK 3. Additionally, GTK 4 introduces GtkPopoverMenuBar to replace menubars. These new widgets can only be constructed from menu models, so the porting effort involves switching to menu models and actions.

Tabular menus were rarely used and complicated the menu code, so they have not been brought over to GtkPopoverMenu. If you need complex layout in menu-like popups, consider directly using a GtkPopover instead.

Since menus are gone, GtkMenuButton also lost its ability to show menus, and needs to be used with popovers in GTK 4.

GtkToolbar has been removed

Toolbars were using outdated concepts such as requiring special toolitem widgets. Toolbars should be replaced by using a GtkBox with regular widgets instead and the “toolbar” style class.

…

Adapt to GtkContainer removal

The abstract base class GtkContainer for general containers has been removed. … The affected classes are:
GtkActionBar
GtkBox (and subclasses)
GtkExpander
GtkFixed
GtkFlowBox
GtkGrid
GtkHeaderBar
GtkIconView
GtkInfoBar
GtkListBox
GtkNotebook
GtkPaned
GtkStack
GtkTextView
GtkTreeView

…

Adapt to GtkBin removal

The abstract base class GtkBin for single-child containers has been removed. … The affected classes are:
GtkAspectFrame
GtkButton (and subclasses)
GtkComboBox
GtkFlowBoxChild
GtkFrame
GtkListBoxRow
GtkOverlay
GtkPopover
GtkRevealer
GtkScrolledWindow
GtkSearchBar
GtkViewport
GtkWindow (and subclasses)

This must be a nightmare for any GTK developer!

👉 Finally, in the aforementioned thread, and after an interesting GTK 4: What’s New, What’s Improved and What’s Worse (with screenshots, so go there for the details!) the same Gordon Squash had a huge essay On the Projected Future of GTK: Part 1, Part 2. Extrapolating to GTK 4 and Beyond:

Where are we today?

GTK is in a situation today which it has never experienced before. For every other major move the GTK community makes, there are between 1 and 10 nasty remarks about the major move from other members of the community. Some say that the GTK team makes unilateral decisions based solely on their priorities, without consulting any other section of the community first. Others claim that many of their explanations for why they changed something are totally unbiased and that their explanations are mere excuses in disguise. Few open-source projects have ever been so fervently detracted in the same manner that GTK and GNOME have been. As of this writing, even Linus Torvalds continues to disfavor GNOME due to its strikingly “unappealing” interface.

Futhermore, many continue to pine for days gone by when “GTK” meant “GTK+ 2”. These advocates for GTK+ 2 were satisfied with GTK as it stood in the months before GTK+ 3 was released. Or were they?

Well, what I know is the opposite: Linus Torvalds is using Fedora with GNOME!

A brief history of GTK in “prehistoric” times

Perhaps many of us have heard that GTK is a direct descendant of the image editing program the GIMP. The fact is, the GTK as we know it today is not the GTK that was the “Gimp ToolKit” (that’s where it got its name) in very many ways at all.

In fact, initially the GIMP didn’t use GTK at all. When Spencer Kimball and Peter Mattis began writing the GIMP as a class project while studying at the University of California Berkeley, they initially used the popular and then-closed-source Motif graphical toolkit. It was proprietary and purchasing a license for the software could be costly; however they used the version of Motif licensed to the school.

Motif was capable of creating workable user interfaces with relatively little code (prior to Motif and other widget toolkits, it was often necessary to write hundreds or even thousands of lines of code just to draw a button onscreen). However, Motif had several shortcomings which made it difficult to write an image manipulation program with it. In response to Motif’s shortcomings, Mattis and Kimball proceeded to distance themselves from Motif and instead started writing a widget toolkit better adapted to graphics manipulation. Since Motif was closed
source, Mattis and Kimball could not base their toolkit in any way on real Motif source code. However, they did base some of the application programming interface, or mechanism for using the toolkit in programs, on the application programming interface of Motif. They also designed their widget toolkit so that it looked roughly similar to Motif, complete with the pseudo-3D look of the widgets. They called their widget toolkit “GTK”, for “Gimp ToolKit”.

But when their class project was turned in and they completed their exam, they had no idea initially what to do with their labor which they called the “General Image Manipulation Program”, or the GIMP, and the GTK. Seeing that they had spent a lot of time on these programs, they open-sourced the GIMP and by extension the GTK, licensing both under the open-source GNU GPL license. They open-sourced the program so that at least others could reap the benefits of their work.

But this was a game changer in multiple respects: For one, an image manipulation program, albeit only a moderately sophisticated one at the time, had just been open-sourced. This meant that other people could contribute code to the GIMP and see their changes integrated into the next release of the GIMP. Another aspect of the open sourcing was the fact that now there was a widget toolkit which was fully open sourced. At the time, another widget toolkit called Qt had recently been making tidal waves, but it too was largely closed source, maintained by a Norwegian company known as Trolltech. As previously stated, Motif was the industry-standard toolkit of the time, but was also closed source, as was another increasingly popular toolkit of the time, Sun’s OpenLooks. Now there was one contender in the toolkit race which was open source and freely available. Like the GIMP, the GTK was increasingly embraced by the community.

As time went on, it became clear that many toolkits — including Motif and, at the time, GTK — contained a lot of unnecessary code duplication. A widget for a toggle button (a special type of button which alternates between one of two states when clicked) might contain a lot of duplicate code carried over from the widget for a plain button. With object-oriented programming being a hot topic in programming and academic circles at the time, the focus was on being as wasteless as possible when writing code for the GTK. Thus Mattis et al. set to work converting the GTK to code that was somewhat more object-oriented in spirit, and the GTK+, or GTK Improved, was formed. The name has stuck up to — but not including — the present day.

At about the same time that the GTK was being updated to the GTK+, shockwaves hit the community: In 1996, Martin Gräßlin announced that he was working on an attractive desktop environment for UNIX-like systems. His message was generally greeted with applause. However, devoted free software advocates disagreed with his choice to use the then-proprietary Qt toolkit as a base for his project. Sensing that the KDE could have inadvertently led to a licensing nightmare on otherwise open-source UNIX-like operating systems, a few months later the GNU project announced that it would begin development of a competing desktop environment known as GNOME. GNOME would be based on GTK+ and would thus be fully open source.

This was the first time that GTK+ was used for anything other than for the GIMP. At that time, the GNU project was also working on an open-source Motif clone, wittily named LessTif. However, LessTif and Motif both lacked several key features required by a desktop environment; hence, the GNOME project chose to use GTK+. Simultaneously, Mattis and Kimball were losing interest in the GIMP and GTK+ and were also on to other projects, so they were looking for a group to take care of both. The GNU eventually picked up development of both projects and renamed
the GIMP to the “GNU Image Manipulation Program”, which happened to also spell GIMP.

By the time GTK+ 1.0.0 was released by the GNU project in April 1998, Mattis had not contributed since September of the previous year. By this point, the GIMP team had evidently passed control of the GTK on to the GNU project finally. Thus the GTK, or the GTK+ more accurately, ceased to exist as the product of the GIMP team.

The early modern era: GTK+ 1.0.0 through GTK+ 1.2

Despite the GIMP team not contributing much to GTK+ after 1.0.0 was released, GTK+ continued to be called “GTK+”, not “GTK+ 1” or “the GNOME toolkit”. (In error, some people called the GTK+ “the GNOME toolkit” or “the GIMP toolkit”, but in reality it already meant nothing more than the letters themselves.) The GIMP continued to use GTK+, and in the first few years GTK+ quite a bit resembled the original GIMP product.

Though it brought some changes, GTK+ 1.2 was not a particularly sweeping change relative to GTK+ 1.0. The chief differences were minor, mostly technical programming nuances rather than user interface changes. But already some could sense a change coming: For one thing, though the default look and feel still resembled Motif, Red Hat introduced a new theme called Raleigh which looked more modern. Red Hat embraced Raleigh whenever they packaged GTK+, and around this version they started investing large pools of resources into perfecting GTK+ and GNOME in general.

Red Hat became so invested in GNOME and GTK+ that they started to leave the other major desktop environment, KDE, behind. Contemporary rumors indicate Red Hat may have criticized KDE by referring to it using a word inappropriate to bring up in this article. What matters though is that by the time GTK+ 1.2 was released, Red Hat had a vested interest in GTK+ and GNOME, and the GNU project’s interest progressively faded over a period of years.

The start of the peak: GTK+ 2.0.0 to GTK+ 2.8

After GTK+ 1.2’s release in 1999, work began on a major version of GTK+, one which some still pine for today: GTK+ 2. Called 1.3 while still in development, it was ultimately released in March 2002. Though it was a very major change from a programmer’s perspective and it took a long time for programmers to convert their programs to use GTK+ 2, on the user interface GTK+ 2 was not much different initially from GTK+ 1.2 — or even GTK+ 1.0 for that matter. One of the most striking differences was the use of the Raleigh theme by default, replacing the old-fashioned looking (even by then) Motif-esque theme. Again, this change was courtesy of Red Hat — and I personally am in favor of the change because it improved the appearance of applications. Another welcome and visible change was the upgrade to slightly more modern icons. All in all, once applications were ported to use GTK+ 2 and users actually got a chance to see the improvements made by GTK+ 2, it was greeted with much fanfare.

Then the sweeping changes began. Version 2.4 introduced several new features, among them a brand new, modern-looking file chooser. GTK+ 2.8 was special in that the changes it brought were mainly visible only to the eagle-eyed observer — instead of rendering onscreen elements using a classical method which produced less-than-smooth results, GTK+ switched to mostly using Cairo, a new graphics library with support for several important graphics features. One of these features was antialiasing — the practice of “fuzzing” the picture very slightly to reduce the grainy “pixellation” which used to plague graphics software; the other main feature was media independence — the ability for the same code to draw the same shape whether the ultimate destination for the image was a printer, a normal computer monitor, a plotter, an image file… you name it; Cairo could support it.

The adoptance of Cairo excited programmers considerably, since now the printing architecture could be greatly simplified. Previously, the printing mechanism was very complicated and involved using code unlike that for drawing onscreen; after Cairo was adopted, printing could be accomplished with only a slight amount of code on top of what was already being used to draw onscreen.

The peak: GTK+ 2.10 through GTK+ 2.18

By the time GTK+ 2.10 was released, Cairo was used by GTK+ for practically all rendering, whether onscreen or in print form. New Linux distributions (the name given to distributions of the Linux kernel plus other open-source software including GNU) had been popping up long before GTK+ 2.10 was released in late August 2006. Red Hat had long been the champion in the Linux distribution field. However, few distributions had gained popularity as quickly as Ubuntu, whose first release was announced in October 2004. By the end of 2006 Ubuntu had gained a significant following due to its ease of use — and the GNOME desktop used by the distribution, GNOME still being based on the GTK+ (but this time version 2), was at the center of the usability improvements. By this time, most distributions had removed GTK+ 1.2 and 1.0 from their repositories of software, leaving only GTK+ 2. Even Debian, long known to be conservative and careful about including only software that was well-tested, started preparing for the eventual elimination of GTK+ 1.2, the elimination finally taking place in very late 2007.

As GNOME progressively became the most popular desktop environment on UNIX-like operating systems, GTK+ 2’s populartity came with GNOME’s. By this point in time, hundreds of people had contributed to both projects and new features were implemented in each new release, sometimes as many as 20 in jam-packed releases. What’s more, more projects than just GNOME and the GIMP were utilizing GTK+ by now — entire other desktop environments such as XFCE had been using GTK+ since about 2000, while entirely new desktop environments such as LXDE used GTK+ from the start. Application developers were writing their programs using GTK+ to get widespread adoptance of their applications — at one point it seemed the GNOME project had too many applications, since the number of applications in the project was starting to dwarf the number of KDE applications. (And that is saying a lot: At the time, the bar for the quality of new KDE applications was, quite frankly, set extremely low.)

Despite it not seeming like an especially important point, theme developers also enjoyed GNOME. Theme developers had at their disposal a number of so-called “theme engines” — libraries of code which could be used to produce a working theme, as long as the theme designer provided a list of stylistic parameters to the theme engine such as what colors to use in the theme. Because theme designers did not necessarily need to write any actual code to produce a working theme, theme designers jumped on GNOME and produced dozens if not hundreds of themes for GNOME. By extension, other desktop environments could use the same themes that were used primarily for GNOME, because the themes were really nothing more than GTK+ themes. Eventually, developers from all of the major desktop environment development teams were writing themes, theme engines, and even code for GTK+ — and seeing their changes become part of GTK+ and, sometimes, part of the GNOME theme collection. This was the peak of GTK+’s popularity.

The long-anticipated successor: GTK+ 3 is on the way

Shortly after GTK+ 2 was first released in 2002, the GTK+ documentation included a section on porting applications to use GTK+ 2 when they had formerly been using GTK+ 1.2 or even 1.0:

GTK+ changed fairly substantially from version 1.2 to 2.0, much more so than from 1.0 to 1.2. Subsequent updates (possibilities are 2.0 to 2.2, 2.2 to 2.4, then to 3.0) will almost certainly be much, much smaller.

In reality, GTK+ 3.0 would take many more years to materialize than the GTK+ developers thought it would. If GTK+ 3.0 had appeared when they originally figured it would, then GTK+ 3.0 would have been released circa December 2004. In reality it would be released more than six years after that proposed date.

By 2007, conversation among the GTK+ community about GTK+ 3 resurfaced. Initially, the general consensus was that GTK+ 3 would not be much different from GTK+ 2 from the developer’s perspective. However, by 2008 it became clear that the World Wide Web was becoming far more graphical than it had once been. At one time, the Web served solely to provide textual information and maybe a few images and, at the very most, video and animation with audio. Despite the adoptance of multimedia on Web pages, it took until consumer computers became more powerful before the multimedia could be plastered everywhere on the Web pages — literally, from one perspective. By 2008 Web pages were becoming so fancy and colorful that some people recognized that the Web pages were starting to look less like drab black text on a white background, and more like the user’s main desktop environment.

The technology which permitted such flexible styling of Web pages was CSS. On one level, CSS is nothing more than a textual means of expressing style information. But the genius is in the way the style information is inherited: In HTML, the language used to lay out Web pages, a Web page is hierarchical; a block of bold text may be enclosed in a paragraph of otherwise unstyled text, for example. CSS gives the Web page designer the ability to style entire blocks of Web pages and all of its “children” blocks too. Or CSS can be used to just style one or two elements. The inheritance properties of CSS make it ideal for styling Web pages, where there may be tens of thousands of these blocks, or “elements”, all on one page and many of them share style properties in common, such as the color of the text or the alignment of the elements themselves.

As we found out earlier, GTK+ is also very hierarchical. A window may contain container widgets, special widgets which can be used to size and dimension other widgets onscreen, even effectively hiding some from view. A window itself is a container widget; a widget dimensioned by a parent container widget is said to be contained in that container widget. At this, one GTK+ developer thought (maybe it was an original thought, perhaps not — we may never know): Why not style widgets using CSS?

The idea attracted enough attention that a new theme engine for GTK+ 2 was written — this time based around CSS styling, however. It did not become successful, however, because most themes were already written in the traditional form and not using CSS. Additionally, GTK+ provided even more styling flexibility than what CSS could afford at the time. Ultimately, only a few themes were written for GTK+ 2 using CSS, most of which were written by the author of the CSS theme engine.

Meanwhile, as more details of the upcoming GTK+ 3 became known, it was eventually revealed that GTK+ 3 would most likely be styled using CSS — except not merely as a theme engine, but integrated into GTK+ 3 itself. Additionally, extensions would be made to the CSS parser in GTK+ 3 to ensure that sufficient styling capabilities were available to themes and applications alike. Though some already felt uneasy about the coming change, many at the time felt it was a change for the better. Additionally, it was planned to continue supporting traditional themes and theme engines too.

Closing in: GTK+ 3 in the later months of development

By 2011, GTK+ 2 was the most widely used graphical toolkit on UNIX-like operating systems. Its popularity seemingly could not be greater. But it had been nine years since a new major release had been produced, and many believed that some former release of GTK+ 2, possibly GTK+ 2.8, should have been named “GTK+ 3” due to its dissimilarity to previous versions. But by 2011 it was too late to rename any version of GTK+ 2 to a new major version, because GTK+ 3 was supposedly around the corner. Or was it?

On the last day of January 2011, another version of GTK+ 2 was released, seemingly in a slight panic: GTK+ 2.24. In many ways this release was never meant to exist: GTK+ 3 was supposed to have been released by December 2010. And yet GTK+ 3 had not been released even by the end of January 2011, much less December 2010. What was going on?

Among the many problems the GTK+ team faced, they realized that the CSS styling infrastructure did not integrate well with the old theme engine system. After much discussion, the package of popular GTK+ theme engines maintained by the GTK+ team for GTK+ 3 was dropped. In addition, the default theme, long known as Raleigh by this time, was hurriedly rewritten for GTK+ 3 in CSS. The hurried nature of the operation, combined with the fact that the theme was supposed to look “more modern”, lead to a less-than-perfect default appearance for GTK+ 3. But this was not a significant problem for GNOME, because in parallel they were working on a theme written from the ground up to look modern. The theme was originally called GNOME3, but was soon renamed Adwaita.

A few days later, on February 10, 2011, GTK+ 3.0.0 was finally released. But before GTK+ 3.0 was finally released, the third major release of GNOME, dubbed GNOME 3, was produced. It was specially optimized to have a “more modern” user interface — one adapted properly to touchscreens, becoming ever more popular at that time. In a strange twist which few people realize, the first few versions of GNOME 3 actually used GTK+ 2, because GTK+ 3 was not yet stable enough for production use. So for a time it was entirely possible to run a GNOME 3 system with classic GTK+ 2 themes, most notably Clearlooks, which had become the default GNOME 2 theme years earlier. But the rest of the user interface was clearly not intended to be used in a more traditional setup. Initially GNOME 3 sold itself as being more “keyboard-oriented” than most desktop environments; eventually it became clear that it was only more touchscreen-friendly.

What was all the hype about anyway: GTK+ 3.0 through GTK+ 3.8

While GNOME 3 continued to disappoint users and Linux distributors alike, GTK+ 3 was just as disappointing to many application developers. Besides the removal of features deprecated in GTK+ 2 (including the old-style, non-Cairo drawing system, and the “ruler” widget which was used chiefly by the GIMP by this point), and additionally the addition of CSS styling, GTK+ 3 seemed to many people just to be much ado about nothing. Many GTK+-based projects did not immediately embrace GTK+ 3 because it seemed to have flopped — whereas GTK+ 2 was not expected to have been much, GTK+ 3 had been promoted for years and it had not lived up to its name. Despite this hurdle, one of the first users of GTK+ 3 besides GNOME was Mozilla, which began work on a GTK+ 3 port of its applications by late March 2011. But like most other projects which jumped into the game early, no Mozilla applications were officially built with GTK+ 3 for years to come.

In addition, the fact that only GNOME was actually seriously being ported to GTK+ 3 at the time led many to believe that GTK+ 3 was the mere product of GNOME developers — and even at that time, the skeptics were correct. Furthermore as GNOME 2 users failed to upgrade to GNOME 3, the user base of GTK+ 3 was limited solely to users and developers in favor of GNOME 3, as if there were any outsiders present from the start of GTK+ 3’s release. Because of this, the GTK+ 3 team believed that they could do whatever they wanted to do in GTK+ 3 — making it more GNOME-centric and forgetting about the rest of the community, for example. If it’s just us using this GTK+ 3 toolkit, then why not adapt it to us and us solely?

Even theme designers (for the most part) did not like the CSS styling: Writing a new theme no longer required just supplying some parameters to one or more pre-made theme engines; it required copying all the CSS code from one theme, often hundreds of kilobytes of it, and rewriting the CSS code slightly. CSS files could not be shared, unlike theme engines which could be shared between one theme and another. In addition, oftentimes a GTK+ 3 theme would require a number of image files, since some widgets were complicated enough that they did not adapt well to pure CSS. Some theme developers were lazy and took screenshots of parts of old widgets drawn using their old theme engines; others took the time to recreate their widgets in scalable image form as SVGs. The former had the disadvantage that widgets looked fine when rendered normally, but when accidentally rendered too large or too small, even the tiniest amounts by applications like Mozilla, they would look blurry and their exact meaning would be unclear. SVGs looked good even scaled up or down, but they had the disadvantage that they too were often created shabbily, and even when properly drawn they could cumulatively consume hundreds of kilobytes of disk space. On the one hand, disk space was not a major concern anymore; but on the other hand themes could easily add up to noticeably increase the size of the GTK+ library if built in. All in all, the built-in themes in a modern version of GTK+ 3 total up to 2 MB themselves — while the size of the library itself, including the themes embedded within, is 8 MB. So these themes effectively increase the size of the library by 33% — a sizeable factor considering that the default theme used by GTK+ 2 amounted to 120 KB of compiled code, which is just 2.4% of the 5 MB GTK+ 2 library.

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.

Hang on, there’s still a bit of it:

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.

Yeah, I know, you didn’t read everything. Blame Gordon, not me. A couple of quick questions then:

How will XFCE look like in 2030? In some Ubuntu LTS, obviously. Most likely installed via the Snap Store.

Should you be using KDE Plasma instead, do you really think it will still look even remotely similar to what it is today? Not because of the changes in Qt, but because Plasma is a crazy thing in itself, only with a much shorter history!

LATE EDIT: LibreOffice seems to be getting a GTK4 port: first cut; some more progress; the Print dialog; MenuButtons; more MenuButtons.

from Hacker News https://ift.tt/ZWntFX6