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

Thoughts & Feedback
,
#1

Hey Folks,
I'd like to start by saying thanks to the MATE Desktop and Ubuntu MATE teams for being lifesavers since the GNOME devs abandoned us to persue their experimental fantasies a few years ago. I personally discovered MATE after an Ubuntu upgrade left me with a choice between Unity and a very early and rather half-baked version of GNOME3 - both were completely unacceptable and then MATE (on Linux Mint at the time) came to my rescue.
Since then I migrated to Ubuntu MATE edition on 18.04, in particular because it has a much 'purer' edition of MATE that is closer to the original GNOME2 layout that I prefer - Just enable the 'TradionalOK' (a-la Clearlooks) theme and it's pretty much good to go!

All that said, I got a nasty shock when I recently upgraded from 18.04 to 20.04 (after fixing the unbootable GRUB installation it left me with!) because a number of bundled applications have adopted GTK3 / GNOME 3 UI 'design' including:

  • Replacement of the traditional menu bar with a non-standard title bar
  • 'Hamburger' menus
  • Most of those menu buttons plus some context menus being replaced with what GTK3 calls 'popovers'
  • Title bars with embedded menus do not inherit the title bar theme/colour from the desktop UI

New GTK3 Abomination 20.04
New GTK3 Abomination 20.041022×817 52 KB

These 'popovers' act more like mini Android menus that don't expand on mouse hover and require the use of integral back/forward buttons to navigate!

So far as I can tell most of the core applications from the MATE project itself are still behaving correctly so this is more of a gripe with some of the bundled applications. However, it also looks like many of these applications changed their UI a long time ago (around 2018-ish) so to them this is probably old news despite that fact that we LTS users remain blissfully ignorant until we get the next LTS. In fact there are a few in 18.04 which were already heading in this direction but I never noticed as they weren't applications that I use.

The guilty parties include (at least):

  • "Backups" (Déjà Dup Backup Tool)
  • "Disks" (Gnome Disk Utility)
  • GNote (Replacement for Tomboy Notes)
  • "Passwords and Keys" (seahorse)
  • "Ubuntu MATE Guide" (yelp)
  • "Document Scanner" (simple-scan - Was it really necessary to rename it from Simple Scan?)
  • dconf-editor (Not sure this is installed by default but it is sometimes neccesary for tweaking MATE config)
  • MATE Disk Image Mounter
  • Remmina (not bundled but it's a one-of-a-kind multi Remote Desktop client and its UI is now also horribly borked)

This problem has really triggered me! I made the switch to MATE for the precise reason of avoiding all the touchscreen-centric craziness that was going on in the other mainstream UIs - so it's extremely annoying to find that GTK3 and GNOME applications are now having a negative influence on the user experience within MATE. It's made worse by the fact there's now a huge inconsistency between the applications which use a classic menu bar vs those which don't.

I'm not sure if/what can be done about these new title bars as the layout is hard-coded into the applicaitons - their maintainers have actively stripped out the old menu code and replaced it with this piece of horror. It doesn't look like anyone came up with a graceful way to define a menu that can easily be rendered as a hamburger or a classic menu based on user choice so those apps which still support the classic menu bar seem to do so by maintaining a separate definition.

I'd love to start a revloution against this, however I think it will be very hard to convince the various maintainers to reintroduction tradional menus as an option, especially when GTK3 possibly makes it a non-trivial task. We could fork and 'correct' every one of these UIs but that would be a mountain of work and would create even more fragmentation of the app space :frowning:
Perhaps a mixute of approached could help - alternative applications such as using 'gparted' in place of Gnome Disk Utility. Perhaps fork simple scan, fix the UI and introduce it as MATE Doument Scanner?
I'd really love to know whether anyone has other ideas for tackling this problem and also whether it's just me or are other people hating these changes enough to want to undo them?

On the subject of the 'popovers' it looks like can be configured by the calling applications. The GtkMenuButton has a property called 'use-popovers' (with a default of TRUE) which seems to offer a traditional GtkMenu if it's set to FALSE. Aside from asking a great many application devs to expose this property through configuration an alternavtive in my mind could be for Ubuntu MATE to offer a patched alternative build of libgtk3 itself which forces it to be FALSE and/or just ignores it and always produces a GtkMenu. At least then we could possible force all menus and contect-menus to behave properly.
If I can get GTK to build for me then I'll have a go at hacking this myself but can anyone comment on the feasibility using a rebel version of libgtk3 it in the real world?

Thanks for reading my ramblings about this and thanks in advance for any constructive comments on this subject :smiley:

15 Likes
A cross-between Yaru and TraditionalOk? Presenting Yaru ok -- Now an Official MATE Theme!
#2

See this thread, there is a GTK fork in the making.

https://forum.xfce.org/viewtopic.php?id=14023

This became necessary to save MATE, Xfce, LXDE and other traditional desktops when GTK4 arrives.

https://forum.xfce.org/viewtopic.php?pid=58384#p58384

From https://developer.gnome.org/gtk4/3.98/ch32s02.html:

First, menus are going to be eliminated and replaced with popovers:

The GTK developers wrote:

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.

"X11-centric concepts." Oh yeah. Like no other windowing system has ever supported menus. Reality check: Wrong! Practically every windowing system on the planet has menu support, even ancient Mac OS and the Apple Lisa. Even Wayland, which is supposed to be relatively bloat-free, has support for the window types required to draw menus.

Next, and possibly even worse, toolbars are going to be removed:

The GTK developers wrote:

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.

I don't care if there's a "toolbar" style class -- based on the GNOME-style user interfaces these days, I'd have to imagine even the style class is going eventually.

Somebody even decided to remove GtkContainer and GtkBin . They didn't even give a reason for that one:

The GTK developers wrote:

The abstract base class GtkContainer for general containers has been removed. The former subclasses are now derived directly from GtkWidget, and have class-specific add() and remove() functions.

Isn't the whole reason for object-oriented programming to avoid re-inventing the wheel? I mean, come on. Now all former container widgets must implement all that code that used to be implemented in GtkContainer.

There are even more examples of annoying little things they've done in that article I linked to. I just don't have time to rattle them all off.

5 Likes
#3

Thanks for this quick reply - I'm not surprised that some folks are taking umbridge at this nonsense from the GTK devs.
I remember back when GNOME Shell was new that a colleague of mine dared to complain that switching between running applications with ALT+TAB didn't work and was told that it was by design and they were't going to implement it because it was the legacy way or whatever... I already got the impression from that, that the GNOME/GTK developers seem to be extremely arrogant and keen to trash all established concepts in favour of fashionable trends - it's all very depressing.
Given that Unity got abandoned at least in part for its insistance of going touch-centric at the expense of tradional users, and even Windows' with the Metro/TIFKAM interface is loathed by many; I don't get why the GNOME developers think they'll be any more successful in the long term.

The idea of STLWRT library to support GTK2 and 3 applications looks promising but also very ambitions.. If it can work, that would be amazing and I'll certainly be up for testing the first release.

4 Likes
#4

Some new gtk apps actually have started offering the ability to switch back (for example,drawing, also foliate has an experimental option that doesn't fully work yet)
I personally don't mind some gnome 3 style apps as long as they are pretty basic like document scanner, but for something like a file manager no way. I think it's good that MATE can use gnome 3 style apps, but I agree that there are starting to be too many, but sometimes unfortunately it can be hard to find decent gtk alternatives.

#5

STLWRT is very interesting - thanks for sharing that @mrtribute. I hope it takes off and steals the spotlight when GTK4 inevitably arrives.

The undesirable GTK3 is one reason why I jumped to a Qt desktop (KDE). I like toolbars and menu icons so I essentially laid most things out the same way as GNOME 2, except no "Applications, Places, System" (though KDE's Application Launcher is like Brisk Menu)

The "GTK3 / GNOME 3 UI design" is called CSD (Client Side Decoration). There is a package called gtk3-nocsd in Ubuntu that should stomp them out of the window. For example, GNOME Disks looks a bit better:

Screenshot_20200604_170520
Screenshot_20200604_170520849×211 12.6 KB

There is a (just recently abandoned) project called gtk3-mushrooms that patches a whole bunch of GTK3 nuisances. It was packaged for Arch (AUR) which I've been using for many months. I just recently updated the patches so it works for GTK 3.24.20.

Over in Ubuntu, @Norbert_X managed to get a script working in Ubuntu MATE 18.04 to 19.10:

Some day I might package gtk3-mushrooms in an Ubuntu PPA (if there isn't one already) - which would be easier then compiling and risk breaking GTK on the system!

3 Likes
#6

Thanks for reminding, I have really forgot about doing this :slight_smile: .
So I have just updated it to support Ubuntu MATE 20.04 LTS

What is really great is that screenshots of GNOME DIsks and Deja Dup now looks good, they do not have transparent rectangles around them:

GtkFileChooser looks good too:

save
save1360×652 163 KB

Patches do not fix simple-scan hamburger menu :frowning:

Installing gtk3-nocsd instead of gtk3-mushrooms force windows to be more ugly than ever:

gtk3-nocsd
gtk3-nocsd622×528 57.4 KB

I have tried to search for gtk3-mushrooms package in PPAs with no luck. So they are presented only in AUR and marked Flagged out-of-date (2020-05-20)".

All these problems is a kind of answer why I'm still using Ubuntu MATE 16.04 LTS which is now EOL. But its look and feel is more consistent.

3 Likes
#7

I completely agree regarding lack of good alternatives. I haven't found anything to replace simple scan as yet - I could use Xsane but it's way more complicated than I need. What I've done for now is to install the .deb package from 18.04 which fortunately still works but it's not really a fix.
Some alternatives could arise from forked versions that revert to traditional UI elements, however it would be so much more constructive if these applications just gave people the choice between tradional / modern UI even if that does mean a bit of extra code to maintain.

1 Like
#8

Well, I thought I'd let you know that the guy writing this thing known as STLWRT is right here on this particular forum now. You can ask me questions here if you want to know more about STLWRT and how it's coming.

I'm glad that by writing STLWRT I'll be helping more than just myself.

By the way, I'm wondering myself whether anybody else would have come along and forked GTK like I did if I hadn't started this project. I'm guessing that in the year 2024 somebody else would have come along and did so, but they probably wouldn't have implemented some of the wacky features that I'm implementing in STLWRT right now.

Ask me about what these wacky features may be!

7 Likes
#9

Just a question about in the future, will this work fine in wayland as MATE is slowly moving to have Wayland capabilities

#10

This is fantastic news indeed! I'm very glad to hear you're writing STLWRT (is it intentionally meant to resemble and/or be pronounced like the word Stalwart?) I'm going to be seriously impressed if it's able to cleanly sweep up all the menu buttons from a GTK3 title bar and place them nearly into a traditonal menu bar!

What whacky feature are you implementing right now? :smiley:

I'd be only too hapy to become an early tester of this - I've seen from your other posts that you just might be dropping a preview around the July timeframe :+1:

I'm not a GTK+ developer but I can read and hack most C-like languages, and have previously done some GTK debugging in Thunderbird - If I can help at all then let me know.

Of the other options presented so far, I think I'd prefer the approach of gtk3-nocsd of using LD_PRELOAD with an interposing library but the amount of stuff that needs 'fixing' may quickly outgrow that approach.. The gtk-mushrooms project creates a heavily patched alternative version of libgtk3 which is more along the lines of what I was going to try for myself as a hack. All this could be avoided if the GTK devs could take a step down from their soap boxes and start accepting that tradional GUIs have survived so long because they were the best solution and don't need reinventing.
Fine, let GNOME have some new-fangled unique, snazzy UI with hamburgers - add a side order of fries if they like, but let all the other envs that use GTK have the choice as to how their GUI and menus get rendered :pray:

As I'm not expecting any miracles from GTK let's see if STLWRT can give us what we all need to be able to be happy with our desktop environment once more :smiley:

4 Likes
#11

First off, I'd like to give everyone the news here -- I was previously discussing STLWRT on the Pale Moon forum (forum.palemoon.org). Because I "wasn't following forum rules" (that's a lie, I was following just about every forum rule and I only recently violated one minor rule), and because the moderator thought I was peddling "vaporware" (I said it wouldn't be available until July -- the moderator was just impatient), I got kicked off. I'm incensed because I had the ball rolling and now those people I talked to on the Pale Moon forum are inaccessible (or maybe I'm only temporarily banned). I do not know the real reason why I got kicked off, but I have a theory: In one of my posts, I used the word "emojis" as the plural form of "emoji". The moderator on that forum told me that actually, the only proper plural form of "emoji" is "emoticons" and said "there is a difference". Well, recently I had had a semantics battle with another user on the forum who was trying to tell me that most operating systems have support for plus signs in file names (don't ask). That previous battle was a bloody one which never came to a conclusion. So I resolved that the next semantics battle I had with someone, I would provide rock-solid proof that they were wrong. So that is what I did to the moderator: I gave the moderator a reference to Wikitionary, the free dictionary, where it said very clearly that "emojis" is the valid plural of "emoji". Furthermore, it even said that the resemblance between "emoji" and "emoticon" was purely coincidental. I said this in a very matter-of-fact manner and did not act aggressively whatsoever. But I believe that triggered him to kick me off; he is well known for being triggered by seemingly tiny things now that he has great power over the forum.

Anyway, STLWRT is indeed pronounced "stalwart" (or stall-writ if you prefer). It is not a coincidence that it's pronounced "stalwart" -- I initially wanted STLWRT to be able to emulate both GTK+ 2 and GTK+ 3. The name "GTK" contains three letters. I wanted to call my project "stalwart" but wanted to give it some resemblance to the name "GTK"; since double of 3 (the length in characters of the GTK name) is 6, I trimmed "stalwart" down to 6 characters, eliminating vowels in the process, and capitalized it to give it even more resemblance to the name "GTK". Now isn't that ingenious? :wink:

As for whacky features, I'm currently writing STLWRT so that in the future it can emulate almost any toolkit -- not just GTK. As unlikely as it may sound, eventually I plan on adding support for FLTK, Motif and maybe Qt emulation -- so you can run applications which require those toolkits without installing those toolkits per se. STLWRT is now ours; we're no longer subject to the rules set down by the GTK project, and thus we can do anything we want to do.

If anybody's wondering about the vaporware aspects of STLWRT, sure maybe I've not given any proof of its existence yet, but I'm speaking early so that nobody happens to duplicate my work while I'm still working on this complicated project.

I personally think that stuff like gtk3-nocsd and gtk-mushrooms are just hacks around a broken system and that we need a real revolution, i.e. STLWRT, to get any change. And I think a side order of fries with that hamburger menu might just change everything after all. :wink:

Please, please do not drop me like that other forum just did. I'd like some continued patience at least until I release this thing. It'll only be a month.

5 Likes
#12

Wow! Well I've learnt a bit about emojis and emoticons then - I always assumed they were largely one-in-the-same thing :laughing:
With any luck, this forum may be a better outlet than PaleMoon anyway I'd argue this GTK issue is much more central to the whole desktop experience than to just a single web browser.

I guess you did start out by using the word 'whacky'! I must admit that I'd never heard of FLTK before and I've not knowingly used anything based on Motif since my SPARC Solaris days at Sun but I can see how emulating Motif to give a much prettier GTK2+ style look and feel could be desireable. As for Qt - I don't know. There's lots of Qt based applications which I really like, and they even manage to achieve a consistent look across other OSes too; so I'm not sure about emulating that one but I won't knock it until I've tried it.

For now I'll wait with bated breath for your first-drop release of STLWRT :smiley:

1 Like
#13

Well welcome aboard @gordon! I'm sure you'll have a pleasant stay, as there's a bunch of us who really dig the look & feel of GTK2 widgets, buttons, icons and menus.

May be of interest - we collated a list of GTK3 "regressions" from this retrospective:

Have you considered where you'll be putting the source code for STLWRT? GitHub would be a good outlet - even if it's still not release ready - I can watch for releases and give it a star. :star:

2 Likes
#14

Yeah, thanks everybody, I'm glad I have support still even after that moderator kicked me off my own thread. Thanks for the list of regressions @lah7! @mrtribute referred me to you a while ago, claiming that you were interested in GTK+ 2 looks applied to modern MATE.

I think I shall post my code to GitHub, actually probably now even though I'm not ready to produce a release -- just to show people that yes, this is not a bunch of hot air. And indeed also to show the disgruntled moderator that I wasn't peddling "vaporware" [word that starts with a B and ends with a T and is 8 characters long]. That's what he said!

According to one member on the Pale Moon forum, Motif is still used and is apparently alive and well -- in the commercial sector. It's open source now, under the LGPL. Cool! But it still has that ugly look and feel that looks so 1980's. :laughing: Not cool! (OK. I don't mind Motif by itself. It's just that it doesn't look right with an otherwise styled desktop.)

FLTK is a lesser-known widget toolkit which in some ways attempts to replicate Motif in terms of simplicity and lightweightness. Some applications I know of which use it include TigerVNC, Fifth (the hot Web browser back in 2015), and many applications written for the DSL GNU / Linux distribution and Tiny Core Linux. It's got a niche user base, in other words.

Qt will be a tough nut to crack, but I suspect even Qt may start to veer like GTK did eventually. So I'm keeping it in reserve.

I'll have much, much more to say in the following days, including soon I will show you a preview of the paradigm I call The Tao of STLWRT. The first part I shall show you is the "ripping" of header bars apart -- using a demo application I created (tongue in cheek): A touchscreen-oriented Linux kernel configurator written by someone who felt it was necessary to bring the existing GTK kernel configurator into the third decade of the third milennium. :roll_eyes:

2 Likes
#15

That sounds like a great idea. My biggest fear was always that your code would somehow vanish. Maybe an irrational fear, but the project is simply too important if we want traditional desktops in the future.

I really like the Qt integration that is possible with gtk2. I hope this will be possible at some point with STLWRT. But one thing at a time. As I said I think it would be great to get the code out there even if nobody will use it for the time being.

#16

Now here's the visual demonstration I promised yesterday. This demonstration is just a crude demonstration rigged up not with STLWRT (I introduced a minor bug and it doesn't compile right this minute) but in GTK+ 3, using Glade. I just whipped up a sample user interface in a few minutes to give you a better idea of what I'm aiming for, when I talk about "ripping header bars apart".

Please note that I would never willingly develop an application like the following; creating the user interface was for me a great source of humor and had me rolling in the aisles yesterday.

Suppose a disgruntled kernel hacker were to create a touchscreen-optimized kernel configurator and then erase all other kernel configurators so you had no choice but to use this piece of junk. This is my visualization of the configurator (complete with hamburger menu, open in the picture):

ts-kernel-config-menu-open
ts-kernel-config-menu-open617×600 35.2 KB

(OK. Maybe it's not a perfect example of touchscreen friendliness. But I hope you get the idea.) My idea is to have a database STLWRT uses to apply rules to various widgets in the header bar, to reorganize the window more like this:
(I wish I could show you in this post, but new users on this forum are allowed only one picture per post)

#17

OK. Here's the STLWRT-ized version:

stlwrtized
stlwrtized644×523 42 KB

I'll arrive another time to show you what's in the menu...

4 Likes
#18

Hello gordon

All this is way above my head, I am a mere user of the hard work of developers.

However, that being said, the first time I was confronted with a "hamburger" menu (at work, Redmond-OS) someone had to point it out to me - I could not find a menu in a new piece of software and was expressing my "frustration". A young colleague came to my rescue. :slightly_smiling_face:

From what has been posted above, GTK4 sounds "like a bad place to be" as far as I can tell. I like menus, I like toolbars.

I wish you success with your undertaking. :slightly_smiling_face:

1 Like
#19

@Bernie: I have no reason to believe STLWRT can't be made to work with Wayland eventually; in fact, I'm allowing for that possibility now so that adding the code to implement Wayland will be easy. On the topic of Wayland, I noticed that KWin (the KDE window manager) can act as a Wayland compositor, and can even draw title bars and window borders like an old X11 window manager -- maybe that would be useful in Marco?

And alpinejohn: Thank you for your encouragement. (I would include you as a "mentioned user", but with my privilege level on this forum, I can't.)

Now as for STLWRT itself. @mrtribute suggested a live ISO containing some desktop environment built for GTK and STLWRT in place of GTK. I was originally thinking in terms of Debian, but threw that one out when I realized Debian still seems to ship with MATE 1.8 (from 2013). That version is so old it uses GTK+ 2 -- not exactly much of a challenge for STLWRT, which is intended to be able to run GTK+ 3 applications. I'd absolutely love to use Ubuntu MATE and please this glorious community (I've been an Ubuntu MATE user since 2016), but I have one reservation: Ubuntu MATE is now only available for 64-bit systems. That's a pity, since I think STLWRT will also benefit users of our classic PC hardware among other platforms. It's also a pity since, as unlikely as it may sound, I regularly use a Pentium III and a Pentium II occasionally. Those are definitely not 64-bit, so I'd be limited to running my own spin of Ubuntu MATE on only one system I have. Any suggestions? This is one holdup of STLWRT, so any help is appreciated.

1 Like
#20

I think Debian 10 uses MATE 1.16 which would be gtk 3 based not to chase you from Ubuntu MATE, but 18.04 with MATE 1.18 or 1.20 were the last to have 32bit builds, although 18.04 is still supported for another year