Horrible GTK3 / GNOME UI design is leaking into Ubuntu Mate applications in 20.04

Well, it's been a long time since I last gave a status update. So here I am again.

STLWRT continues to come along, although its development has slowed lately: I've recently gotten a flood of feature requests coming my way, feature requests for GTK-based applications. Many people recognize that I am skilled at writing GTK-based applications and additions to existing GTK-based applications and I am now at the center of an endless stream of requests. I think I had better start turning down requests a few at a time, at least new requests...

(By the way, if anyone reading this happens to be someone who has requested a feature from me, don't feel put down. It's really up to me to turn down feature requests.)

More interestingly, I was searching through my records about STLWRT and found these two pictures which I hadn't bothered to post yet. The first one shows an application, the MATE Accessibility Preferences, which was compiled against GTK+ 3 but was running on STLWRT. Note that it is fully themed, using the classic Clearlooks GTK+ 2 theme engine. The second picture is probably more interesting, as everything in the picture, from the application windows to the window manager (yes, even Marco, the MATE window manager), is using STLWRT. Plus the picture shows off STLWRT's default use of classic GTK+ 2.10-era icons, which I personally think are better looking than the GTK+ 2.12-era Tango icons, at least with the default theme.

Presented with no further comment:

MATE_AT_PROPERTIES_on_STLWRT_0.0.20_with_theme_engine

5 Likes

Thanks so much for the update Gordon - it's looking pretty impressive. Is the git repo up-to-date and in a state where I might stand a chance of compiling STLWRT to try it out? (I do understand that it'll still be very alpha and not ready for general use etc...)

1 Like

The Git repository is right now up-to-date (I just updated it a few seconds before I posted this), but unfortunately you still are going to have trouble compiling it. I truly do not recommend compiling it right now. But I can promise three things to you: One, I'll produce an actual release when it's compilable; two, it should work with a lot of GTK+ 3 applications out of the box; and three, I'll publish a list of applications which definitely work with it. I also have a firm belief that the alpha release is not far off, although I cannot tell you for sure when it'll be ready. That's the unfortunate part. But I can tell you that you probably will not be disappointed with the user interface -- the default theme is a variant of the traditional default GTK+ 2 theme, Raleigh, with a set of truly classic icons (some of which I had to create myself in GIMP). Not to mention many of the more popular theme engines I shall port over to STLWRT -- familiar ones that ring bells like Clearlooks, Crux, ThinIce and Nodoka. (The theme engines I envision as a separate package. We can't use the exact theme engines from GTK+ 2 because STLWRT has to support multiple versions of GTK, and they are not all alike.)

In short: I'm really sorry that it's not compilable yet. :pleading_face: But seriously, I'm basically hand-porting all this code myself -- if anyone wants to help, I'll give very specific instructions on what they can help with and how.

All I can say is, probably GTK 4 will be out before STLWRT is. (I'm pretty sure 4.0.0 is coming circa September 27th.) But we've still got time; it took years before GTK+ 3 got a stranglehold over GTK+ 2. (And the GIMP developers still have a bone to pick with GTK+ 3.) So I'm not too worried about the GTK 4 aspect of things.

By the way, when I come back in a while, I'll give everyone a very detailed update, and an unusual one: What I've found from the bowels of testing the pre-release GTK 4, version 3.99.0 -- and the awful truth about the code itself... complete with pictures and a full review of it on 32-bit as well as 64-bit hardware, usage on X11 as well as on Wayland, use of the default theme versus use of a GTK+ 3 theme, TraditionalOk!

(Slight spoiler alert: Scrollbars still exist in GTK 4, but no more scrollbar steppers -- there's mention of steppers in the documentation, but there's no supporting code left, the documentation is just outdated...)

6 Likes

Does that imply that it was at some point considered to drop them entirely from GTK 4?

I do not think it was discussed (at least publicly). I was saying that as contrast to the removal of the scrollbar steppers, so that nobody got scared that scrollbars themselves might be gone too.

About GTK 4, here comes my appraisal:

GTK 4: What's New, What's Improved and What's Worse

For this test I used GTK 3.99.0, which is still the latest development-quality (i.e., beta-testing) release of GTK 4. I performed the test on Gentoo on 32- and 64-bit Intel-architecture PCs. I was hoping GTK 4 could work (even if a mite slowly) on 32-bit systems, too.

Prerequisites

To give you an idea of how new of software you need to use GTK 4, some of the dependencies are not yet even in the Gentoo repository. And Gentoo is not known to be conservative like Debian. Among the dependencies you might need to install are GLib (2.64 or later), Pango (1.45 or later), SassC (a CSS compiler), and Graphene.

Let me also tell you that I have no faith in the proper functioning of any of these components, including GTK 4 itself (it's a development version, for crying out loud), so I decided to install all of this software under an unusual installation prefix: /opt/gtk4. That way there would be no conflicts.

All libraries and GTK 4 itself compiled and installed cleanly into /opt/gtk4, which I was impressed by. There were compiler warnings, but none of them seemed especially meaningful to me (and I've actually perused the code for these libraries before). I had high hopes at this point.

After compiling on the 32-bit system, I ran the 32-bit version and was disappointed by the fact that the GTK demo application crashed before it even finished drawing the main window. It crashed with a segmentation fault. After hunting around for what might have caused this error, I discovered that the segmentation fault was caused not by an illegal memory access (like most segfaults are), but by a "general protection error". What does that mean? I dusted off an old book of mine about the i386 architecture and discovered that it means a lot of things, but one of the meanings of that fault is that an SSE (advanced high-speed floating-point) instruction was executed with memory "misaligned". When a variable is misaligned in memory, it means that the address of the variable is not evenly divisible by some set power of 2; in my case, the variable's address was not evenly divisible by 16 bytes, because the variable was packed into a structure with several other variables. I ran the 64-bit version of GTK 4 I had just compiled and that version ran fine, leading me to believe that the alignment problem was an issue only on a 32-bit system. (Take that information any way you want to take it.)

Anyway, the rest of the appraisal is for the 64-bit version; I eventually made the 32-bit version partly work, but it would crash sporadically from the same alignment issue anyway, if you continued running the application for more than about 20-60 seconds.

One thing I'll note is that GTK 4 is very obviously intended for Wayland and not so much for X11. It seems the X11 backend has suffered from code rot in multiple places, but one of the myriad places where the code rot appears is a 20-odd pixel gray border that surrounds all windows except for menus. I'll get back to that shortly. But for right now, allow me to apologize for the mediocre screenshots under X11, because it seems GTK 4 applications do not play well with my screenshooter.

Anyway, I tried the demo application under Wayland and X11. The first thing I noticed under both backends was the toolbar buttons did not look like toolbar buttons:

They look like buttons, not toolbar buttons. Toolbar buttons should not be slick on the outside unless your theme actually dictates that. (By the way, the Wayland screenshots always come first, and the X11 shots always come second.) But one thing I remembered is that this was caused by the removal of the dedicated GtkToolbar widget (like I previously outlined and @mrtribute was kind enough to copy into this thread way above). I remembered that the solution suggested by the GTK team themselves was to apply a "toolbar style class" to the section of the user interface with toolbar buttons. I did so myself, and voila! the toolbar buttons looked like toolbar buttons. I hope this is ironed out, because the GTK demo applications are where many developers look to for examples when a new feature is added to GTK.

And you may have noticed that the border does not surround headerbar-less windows, either.

But I'd like to bring your attention to a bad case of hipocrisy, and undefendable hipocrisy to boot: the menus and menu bars. No wait, they're not menus, they're "popover menus"; menus are unwidgets, in George Orwell's terminology, forgotten to the history of GTK, lost down the memory hole apparently. So about these popover menus: As you can see above, obviously menus (sorry, popover menus -- two counts of thoughtcrime there) still exist, but in a rather bastardized form -- now the menus are physically bigger and a lot stupider-looking:

What you unfortunately can't see is that the exact "override-redirect windows" in use by menus (yikes, strike three on thoughtcrime!) are also used by popover menus. I bring this up because "override-redirect windows" were exactly the X11-centric concepts the GTK team were criticizing in the piece I quoted from them above! It's crazy!

And then the popover menus are still kind of flaky right now, with the possibility to select multiple options at once (and no, it's obviously not intended):

But that aside, I also note that the dialogs look (in my opinion) like trash now. And that's not configurable by the theme (I checked the code), and all dialogs are going to be like that unless you attach a dreaded headerbar to them:

Are there any good points to GTK 4? Yes. Now that GTK uses OpenGL for rendering, the speed of the user interface has improved. Now you can scroll up and down a page of text cleanly. But skeptics would argue that they're doing with the GPU what GTK used to do with the CPU just fine.

And the scrollbar steppers: I checked the code up and down and found no evidence that the scrollbar steppers still exist. Dang it, I just committed thoughtcrime again; I mentioned an unwidget, actually two!

I hope that was an informative guide. It at least powered me up to continue STLWRT before it's too late.

Next time: An even deeper review of the future ahead of us...

6 Likes

I wish I could post my full analysis and history of GTK here in one post, but it's far too long for that -- it's an 11-page behemoth and the character limit here is 32,000 characters per post. I hope you can stand the breaking up of the essay into two parts. Here it is in full:


Gordon Squash on the Projected Future of GTK

Extrapolating to GTK 4 and Beyond

In a previous essay I provided my frank review of GTK 4, or the latest
unstable version of said toolkit: 3.99.0. I concluded that it's a step
in the direction that GNOME has been taking for about eight years now.
In this installment of my messages, I'd like to shed light on what I
think is the direction GTK will take -- not just now, but years into
the future of the project.

To do so I will use history as my guide: the past history of GTK --
looking over not just 10 years, but over more than 20 years of history
to find out what the next 10 years and one major release may bring us.

DISCLAIMER: Please note that I do not posess any form of crystal
ball, so my projection may be entirely wrong. Only time will tell.

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

Over the next few sections I'd like to show you why I think it's largely
invalid -- though not totally invalid -- to group favored and disfavored
versions of GTK together into major number distinctions such as "GTK+ 2"
or "GTK+ 3". However, I will warn you that this article is extremely
long and detailed, so if you already know about any of this content you
may consider skipping paragraphs or even pages of information.

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.

9 Likes

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.

18 Likes

Good reads thanks to you, you are quite brave to not follow the GNOMEs. One thing that makes an DE (desktop environment) popular is how many people actually bother to change the default one.

For Ubuntu, default is GNOME DE. And GNOME devs talk a lot at conferences and are good at raking in the money. As for their coding skills, history speaks for itself. See GTK+ 2 above, use Ctrl+F to find occurences or paste text and filter for the words.

I know this is not news, but man you're really good at software dev. Just setup some pages for getting funding for your project, start from the ones that most common folks will use. A Pentium III is just a limiter for you now.

If only people would give the project a cash infusion of say 10 000 USD per month, most Ubuntu users in the world would have a less bleak OS in the future. Please people if you like good software, donate your money and hardware instead to super skilled developers.

Or you will have to keep quiet when it takes 8 gigabytes to run 2 simple apps and a web browser(with 3 tabs) on your raspberry pi in a dependable and safe manner. Or on your desktop, laptop, or smartphone. When it actually requires only 25% of those resources, according to the actual app resource requirements for Linux distribution.

Don't get me started on the UI blunders. Just put a decent help menu for your app in there, instead of complaining about noobish users. No one died of extra usage information for a particular app.


About saving XFCE DE, someone should request or help out with setting up the funding page for https://github.com/Xfce-Classic/libxfce4ui-nocsd , it seems close to dying without funds. And gordon's project, STLWRT I think.

Thanks to Wooloomooloo , saved me some time, I feel the same.
Huge thanks to the Squash for squashing poor quality software engineering, keep it up but get the funds first you ronin ( samurai). Saved me even more time. About 800 000 words is not exactly easy to type straight from the brain.


On behalf of many noobish users I asked, no specially crafted surveys(which get analyzed in a weird way) - GNOME sucks on touchscreens, like dust in your breakfast. So I don't know how to rationalize their position(GNOME devs) without seeming rude.


From intermediate users - X server is awesome. What even is Wayland good for other than another forced down your throat ostentatious "good thing" that makes only its developers feel good.

Like delusional people wrapping everyone in thick lead to protect from radiation. Except, to every normal person, they just harm the innocent people they claim to save or serve.

2 Likes

For the record, I shall point out that GTK 4.0.0 (the first stable release of GTK 4) was released yesterday, the 16th of December 2020. I shall review it soon and see if anything major has happened leading up to this stable release.

2 Likes

I'm really curious, especially if the X11 font rendering was changed in any way compared to the pre-release version.

Thank you @gordon for an excellent article regarding the history of Gnome & the GTK toolkit - it's very appreciated!

After reading your comprehensive article - one starts to ask some difficult questions: Is Gnome some sort of MS (or M$ - as some members here prefer) trojan horse to sow chaos & unnecessary fragmentation in the Linux world? Because if you look at the decisions made by the Gnome leadership - they are alienating & upsetting their users after every new version. Look at how many new DEs were created or forked from Gnome 2 after Gnome 3 was introduced (Mate being one of them). Does a community oriented project do that? No! Does a corporate oriented project do that? You betcha! Has GNU also become the same sort of trojan horse? Richard Stallman "honourably" resigned as the head of the FSF but didn't think it necessary to resign as the head of GNU. Why not? Richard Stallman gives presentations & lectures at MS' campus - MS certainly pays him well - he definitely doesn't do them for free - so is MS/M$ trying to buy off Stallman to get him to influence the Linux world in their favour? Probably yes. That explains why a "community oriented" project would work so damn hard to destroy their own project & upset their own faithful users. The end result is to kill off the Gnome & GTK projects as you correctly predict. Who benefits from that? Definitely not the open source community.

Thankfully, in the open source community projects can be forked and don't become abandonware - so best of luck with your project & hopefully it becomes the successful drop in replacement to GTK! :+1:

Regarding forums - you are spot on! The reason I use Ubuntu/Ubuntu Mate is that the forums are excellent & full of relevant info, the moderators/contributors are helpful & level headed people and they do a good job at weeding out the crazies & the trolls. Linux Mint's forums are also great. All the other forums are definitely not new user friendly & the moderators/contributors are definitely not nice & helpful!

1 Like

@maximuscore: That's a good question, has the font rendering on X11 been improved any. The short answer is no. However, I'm starting to wonder if the difference is really important. This time, I've taken a closer look at the font rendering in GTK 4.

With that said, I would like to show you more about the latest release of GTK 4, and the first stable release: GTK 4.0.0. Expect to see this release or a later micro release, such as GTK 4.0.8, in your favourite Linux distribution (perhaps Ubuntu or a derivative) soon.

I should also note, in big bold text, that I've been conducting most of these experiments on a 32-bit Intel system -- it's apparent that GTK 4 is not supposed to run on such systems. Nevertheless, my quick tests on borrowed 64-bit hardware reveal that similar mishaps occur on 64-bit hardware, too. If I had the time I would report the bug, but alas I don't right now -- should anyone else be truly annoyed by the bug, go ahead and report it.

OK, about the font rendering. On X11 the font rendering is still kind of ugly, showing unevenly thick letters:

This contrasts to Wayland, which doesn't show quite as much ugliness, although it's debatable whether it's perfect (in my opinion it's good enough):

You've seen this stuff before; the interesting part is: why is there a difference between the two? I first figured it had something to do with subpixel smoothing, i.e. placing coloured pixels next to otherwise unsmoothed text. The coloured pixels are intended to enable only the nearest colour components, a.k.a subpixels, to the unsmoothed text, thus making the text look even smoother than normal, "greyscale" smoothing, which uses light and dark shades of grey near the unsmoothed text to make the text look smoother. An example of subpixel smoothing on GTK+ 3.24.22:

GTK-3-24-22-subpixel-smoothing-closeup

It turns out that I was wrong; GTK 4 ignored my desktop settings, using greyscale smoothing even under Wayland. The following shows text (magnified to 7x) drawn by GTK 4 under X11 (left) and Wayland (right):

GTK-4-0-0-font-rendering-X11-and-Wayland

As you can see, no colours to be found in either; obviously, subpixel smoothing is not at play here. However, you may have noticed that the text under Wayland is lower contrast than the text under X11. I then figured that maybe other sub-pixel phenomena may be influencing this minor difference. Sure enough, a quick look at the GTK Inspector reveals that the text under X11 (left) is drawn on an uneven pixel boundary, whereas the text under Wayland is drawn on an even boundary (pertinent areas emphasised):

That's not to say that the Wayland version doesn't have a few bugs, however. The Size Groups demo under Wayland predictably distorts many of the fonts, no matter where you position the demo window:

GTK-4-0-0-Wayland-very-ugly-fonts-in-size-group

But if you unfocus the window, the fonts clear up. Interesting. Note that this mishap does not appear on 64-bit hardware.


But I have a few closing notes. First off, should you want to try out GTK 4 yourself (I encourage doing so), you might prefer to hunt down a binary version from your distribution's repository (the testing versions of Fedora and Ubuntu might include it by the time you read this). However, GTK 4.0.0 has only been out for a few days as I write this, so I'm not expecting your distribution to carry it yet; as such you'll likely have to build it from source code. To do so, I warn you that you'll need at least the following dependencies (minimum versions required also included):

  • Meson: 0.54.0
  • GLib: 2.66.0
  • Pango: 1.47.0
  • FriBiDi: 0.19.7
  • HarfBuzz: 0.9
  • Cairo: 1.14.0
  • GDK-PixBuf: 2.30.0
  • GObject-Introspection: 1.39.0
  • Graphene: 1.9.1
  • Epoxy: 1.4
  • SassC: No version explicitly requested.

Whew! That's a lot of dependencies! (Not really. There are plenty of software packages which require more dependencies than that.) If you're using Gentoo Testing (like I used for my GTK 4 experiments), you'll have the necessary versions of these packages already, apart from Pango. By the way, I installed Pango 1.47.0 system-wide for this GTK 4 test, to ensure that it wasn't the culprit of the font funkiness. It wasn't. If you're using another distribution, check your package manager to see which dependencies you'll need to build yourself.

Second, if you want a smooth experience, use 64-bit hardware. GTK 4 is not designed for 32-bit hardware of any kind. This is clear to me now.

Furthermore, graphics drivers play an even bigger role in GTK's stability than ever before. At one point I tried GTK 4.0.0 on Intel graphics hardware using the Mesa iris driver. Occasionally on Wayland and X11, glitches would appear like this one:

When I switched to the alternative i965 driver, these glitches no longer appeared, but more minor ones started cropping up. Caveat user! In other words, your mileage may vary.


All right. That was a big, huge rant about GTK 4.0.0. Perhaps someone else has something more useful to say? Again, I encourage inquiring minds to try it out for themselves.

Also I feel sorry for the administrators here -- I try to keep the sizes of these images down to a minimum, but it still must be a huge drain.

3 Likes

Thanks for the comparison screenshots.
I wonder how that would look on a Hi-DPI display. I think on the increased pixel density probably makes up for the lack of subpixel-AA.

You're probably right. Unfortunately, I don't have a HiDPI monitor of any kind; I was expecting a box full of parts for a new computer for myself, but it has so far gotten lost in the mail twice and I still don't have it in my hands yet. Much less a HiDPI display.

9 posts were split to a new topic: Discussion about open source philosophy

It's been a while since I said anything, but that doesn't mean I've given up! It just means I've been immersed in code up to my hair.

I now have opened an issue on my GitHub project page to track these early developments of STLWRT, so that this thread doesn't get too clogged with announcements that are not really related to "horrible" design choices.

4 Likes

sorry, I couldn't read even the first part, but damn, that would make for a thesis at the university

Wouldn't it be better to just swich over to qt rather than try to keep GTK alive?

Sadly it's nowhere near that simple.
It would take a huge effort to convert MATE to use Qt, not to mention the inevitable UI changes which would happen even if trying to make it look and feel like the current desktop.
But the biggest issue is that many, if not the majority, of the biggest applications are all built using GTK. Even running KDE (Qt) right now, you'll still be treated to some of the UI horrors of GTK3 when running Firefox or Chrome.
The chances of persuading even a fraction of those applications to convert to Qt or something else would be very slim.
I think the only possible way to have any chance of getting back our long-established UI standards is to beg the GNOME/Gtk developers to re-implement the necessary code with added configuration switches to allow user selection of legacy Vs hipster window management.