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

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.

6 Likes

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.

1 Like

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:

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

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:

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

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

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.

4 Likes

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

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!

8 Likes

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

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

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.

6 Likes

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

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

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

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.

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


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

OK. Here's the STLWRT-ized version:


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

4 Likes

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

@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

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

@gordon In my opinion the 32/64bit distro problem is a longer-term matter. With the first release I'd wholly expect to have to compile it from source on whatever flavour of Linux and then have the the nicer packaging will follow on shortly...
For STLWRT to stand a real chance of gaining traction across the Linux world it ultimately needs to be easily installable by regular end users on all the major distros - at the very least we're going to need to aim for DEB and RPM packages, but I'd imagine that you also need to consider Arch and Gentoo plus others (Despite the fact I've never run Arch Linux, I think it's got some of the best documentation out there which I frequently refer to for other distros - having Arch embrace STLWRT could be quite valuable). I would presume that there's a path available for Ubuntu where you actually get STLWRT included in repos for core 32/64-bit Debian releases, which then cascade to Ubuntu/Mint etc?

And again, just my opinion, but I think it needs to start life as a drop-in alternative to GTK3 which co-exists and has a simple configuration file or tool for users to switch between STLWRT and native GTK3 globally, with some kind of override/exception list to bind specific applications where necessary.

Sure, a Live CD would be cool for demonstrating it but I think the real magic is going to be when you provide an instant fix for users like me who've just upgraded and discovered the true horror of GTK3 for the fist time - here's my take on how it might play out:
Step 1) User upgrades to newest LTS version of favourite distro
Step 2) "OMG! This is horrible! What have they done to the UI? Where's the frakking menu gone? Where's my title bar?" :exploding_head:
Step 3) Google
Step 4) "Ok, so there's this thing called 'STLWRT' that claims to fix this...": <package_manager> install stlwrt
Step 5) "Holy mother of Jehoshaphat! This thing actually works!" :open_mouth:
Step 6) Normality is restored! All is right with the world and we can continue to love our hamburger-free, organic menu bars for eternity :smiley:

P.S. I have high hopes for STLWRT :smiley:

1 Like

@Bernie: Wow. I only saw MATE 1.8 in the repositories. But either way, I'd rather go with Ubuntu MATE, and 18.04 is a good idea. And I thought that since 12.04 the desktop versions have been maintained for five years, instead of the old three?

Perhaps 64-bit users can get Ubuntu MATE STLWRT Edition 20.04 and 32-bit users can use Ubuntu MATE STLWRT Edition 18.04, for now?

And Ovation1357, maybe you're right. Maybe I'll check in with Arch -- unfortunately, Gentoo (ironically!) is lacking a truly configurable package manager -- one of the few things missing from Gentoo's package manager, Portage, is the ability to "Provide" compatibility with one package with another package: So with Debian and Ubuntu, you can say that STLWRT "Provides" GTK+ 2 and GTK+ 3. In Gentoo I know of no way to do such a thing, which means all the ebuilds (package build instructions) will need to get changed to accept either GTK or STLWRT. Not fun.

But I like your idea about the coexistence of GTK and STLWRT. In fact I planned that (to a certain extent). I like your description of the GTK+ 3 discovery process; it's accurate, I must say.

1 Like