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

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:


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


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:


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.


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.


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.

1 Like

Agreed on most points, although the other alternative that one could take is basically to create a new GUI Toolkit and have it licensed under LGPL like GTK/QT and you can transpose code over as needed from the two projects and establish a stable API going forward.

I had to develop my own in house GUI Toolkit from scratch (using C language with Single Inheritance written manually and it doesn't use any of the code from GTK/QT), because that is a much easier alternative compared to arguing with Gnome/GTK folks or forking off GTK. The added bonus is easier binding, because I could maintain a JSON file specifically for binding generator to use and it would end up saving time to allow other programming languages like C#, Python, Ruby, or whatever else out there to use such GUI Toolkit. Only reason why I haven't open source this project is basically I don't feel inclined to deal with all of the backlash from Linux Community for daring to create alternative GUI Toolkit. (Not my first rodeo since the last couple open source projects I've been involved with.)

It important to acknowledge that QT is primarily a C++ project even though they offers "Lite" API bindings like QML, you still have to resort to writing C++ when the project scope extends beyond what Lite API offers such as extending implementation of a given QT object. C++ is extremely difficult to bind to that it's fundamentally impractical unless someone were to go about making a full scale C++ to C transpiler which is a monumental task. Foreign Function Interface is an important considerations when talking about GUI Toolkit.

The practical options going forward are basically you either fork off GTK and maintain a separate branch or to write a whole new GUI Toolkit to provide stable API going forward.

The developer appears to be putting it on hold for a bit but what about the work being done on stlwrt? On mobile so forgive the lack of formatting:

Assuming it works on X11, it should still be ok even to this day, because X11 rarely change if at all. The only concern I would have is whether or not if something changes with Libinput, but that's about it on top of my head.

As the project said, it seems to be on hiatus.

Editted, because this platform doesn't let me make more than 3 replies. Silly if you ask me.

I honestly don't know if that is feasible after seeing the Pop_OS debacle over libadwaita with Gnome/GTK. Gnome/GTK have a history of being uncompromising, so I'd be impressed if anyone managed to convince them.

The difficulty with all of this is that you'd still either need to maintain API compatibility with libgtk, or start maintaining alternative builds of all the major applications which use it otherwise, unless I'm missing something, it would be somewhat pointless..

For example you can already force native window decorations onto a GTK3 application but because they now use so-called 'client side decorations' (CSD) the application still draws its own non-native title bar plus hamburger menu and embedded buttons, it's just all framed by a native window.

I've given this a lot of thought and the only remotely feasible way I can see if this getting fixed is to lobby the GTK Devs to give us back our native menus and widgets :thinking: Just maybe if they can understand that their design choices for the GNOME desktop are having a knock on effect to all other desktops they just might reconsider :man_shrugging:

The problem is that Gnome developers apparently consider this a feature.

I don't think they consider it a feature. I don't think they consider it at all.

No, trust me, they consider it. They just think if it breaks other people's desktops that will make them eventually move away from them and go to Gnome. They're operating under a winner takes all mindset rather than a rising tide lifts all boats mindset.

The thing is if you look closely at gtk4 i did notice : 1) Menubars can be done in gtk4 as well as toolbars. 2) A window shadow and the headerbar can do window decorations. Like back the days of unity they can be themed.
3) It should be possible to replace libadwaita with something different that loads files from disk to a small ram drive-/ressource. Sry but what gbome tells us there is just garbage. Gtk4 cpuld be themed and look as gtk3. Scrollbars could be done with combining some other widgets.