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

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!


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:


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.


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:


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:


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...


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

That sorth of thing would add another layer of software, perhaps a super-duper launcher that would check some list of applications or some env variable, and before launching app override the environment to GTK2/3,QT or Super-DuperTK.
To switch easy for each application, I belive that would have to be implemented in a menu editor. To add launcher to the exec command.
@gordon I gave my best and could not pronounce STL...
Sounded like this scene:

1 Like

OK, that was amusing... :laughing:

I didn't mean to make that sound offensive; in fact, I'm trying to learn a foreign language and pronunciation is very difficult for me.

Which pronunciation did you have trouble with? Stall-wurt, stall-wahrt, or stall-writ? You can pronounce it however you like; I'm not enforcing any pronunciation guidelines upon anybody, I'm too tied up with programming to do that. No reason to feel ashamed. Do you think I should call it something else?


STLWRT seems promising, i'd say upload to github or gitlab as soon as possible, git branching is such an amazing tool for bug management, really saves you headaches, also having the code out there means you don't need to be the only one trying to fix the bug and that people may be able to provide better help with the project.

on the fear of stlwrt still not being release ready, many github repos start not being release ready, just put a "early alpha" notice in the readme file along with a TODO list stating current objectives and features to come ordered with the urgent ones first.

Sta-vit, stal-it... No, no, I don't give up. :smile:
Will get it right by the time you get it ready for launch.
I saw that gtk sets some variables that both gtk2 and gtk3 use. https://developer.gnome.org/gtk3/stable/gtk-running.html
Is it possible to use them to switch between STLWRT and GTK per application?

Maybe. My take on the variables was that GTK+ 2 uses those variables, and GTK+ 3 also happens to use those variables, so you've got to be careful about exactly what value to assign to those variables, or else GTK+ 2 might try to load modules which are only compatible with GTK+ 3, for example.

Ultimately, I think the best way to switch between STLWRT and GTK would to add code to STLWRT to load GTK if STLWRT's configuration says to load GTK instead of STLWRT for that application. But that's in the (relatively near) future.