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

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

Thank you. I'll get it online ASAP, I've just been kinda tied up lately.


I'm happy to see someone taking the lead on forking GTK+ 2, but I'm also curious to grasp what STLWRT vision consists of. Is it intended to be just a compatibility layer or can it be evolved to become what GTK 3 should've been, because there are things that it did improve, like geometry and rendering APIs and the results of Project Ridley.

I quit the whole Pale Moon scene because the author and community were so prickly. But any forum is at the mercy of its moderators. I was permanently banned from a forum where I had been a years' long contributor and had huge reputation, by some a$$hat punk moderator who clearly had a very tiny, um, sense of self-esteem. Yes, that's it, self-esteem :slight_smile:

I think you'll find that folks here are on you side. I have found this to be a most reasonable community...

1 Like

How hard would it be to rewrite the gtk in the MATE desktop to STLWRT, also would it be possible to write interfaces for Python applications, I ask as that is the second most common language used in MATE after C, and also I'm slowly working on learning it to write apps and panel applets for MATE

As I write this I'm uploading STLWRT to GitHub. It's gonna be a long process because I've got a very unreliable Internet connection here, but it'll eventually get through (I hope). I'll be back with a link to the code soon.

That doesn't mean you can try out STLWRT yet. No, rather that means you can look at some of the code, read the README, tell me how stupid you think it is, verify it's not vaporware, offer to contribute some code. I thank you all.

In the meantime, @Bernie:

According to the Tao of STLWRT (tm) (no, just kidding, it's not a trademark -- yet), there's no need to "rewrite" anything to work with STLWRT. It should just be install STLWRT and move on with your computing experience.

To provide a Python interface (or an anything-other-than-C-or-C++-interface, for that matter), GTK uses GObject Introspection, which integrates with the GLib (the low-level library GTK uses to augment the standard C library) and GObject system (which is part of GLib). GObject Introspection basically loads a compiled library (like libgtk-3.so -- that's the main GTK+ 3 library) and provides wrappers for the various functions in the library for Python -- while adding an object-oriented layer of functionality to the whole thing. I plan on keeping GObject Introspection support in STLWRT -- it was present in GTK+ 2 and it's not a huge burden to bear as the maintainer of STLWRT (yet!).

And @mrnhmath...

I'm not familiar with Project Ridley. What was that?

And sure, if you want to be non-conforming to the GTK app-verse, you can use GTK+ 3 functions in your otherwise GTK+ 2 compatible program.

I don't see why not.


It's coming. The upload is a real pain in the behind, to use technical jargon. :slightly_smiling_face: Also my employer has been calling me to do double shifts, thus minimizing my spare time yet further.


Just wanted to say it's really great to have you here, and more so for your efforts in keeping GTK+3 alive and well. Traditional UI/UX paradigms shouldn't be fated by whatever current fashion trend or hipster fad making the rounds.


would it be possible someday to create mobile apps with the toolkit, maybe tie into the good part of libhandy, and i don't mean gnome style, but maybe for a mobile MATE desktop someday

Sure, STLWRT will emulate GTK+ 3 as well, but it's based on the GTK+ 2 codebase, since a lot of people here preferred GTK+ 2 anyway.

One thing at a time, please. Nevertheless, probably. I don't see why not.


don't worry any mobile MATE desktop is probably at least 5 to 10 years away minimum and probably will never happen, I just have some thoughts how it could be implemented :smile: Since it can emulate gtk3 it probably would be able to tie into libhandy pretty easily anyway

Thank you for highlighting this! Even I dislike the touchscreen nonsense which goes with GNOME 3. MATE dev team, its a humble request please STOP converting MATE into GNOME!


I registered here specifically and only because of this thread (I hate registering so it's kind of a big deal for me); trying out the latest Mint Mate I nearly got a stroke at the sight of the numerous "hamburger" menus it harbors, despite me fleeing to Mate exactly and specifically in order to avoid any Gnome3 UI of any kind. Frankly, I feel cornered and I have no idea where else to escape from that abomination to which I will refuse to surrender as long as I still breathe. Feel free to consider this overly dramatic, for me it's a simple truth backed by an infinite supply of stubbornness resisting to be railroaded onto a path I refuse to go down. @gordon if your project can fix this, I'm willing to sacrifice virgins on your altar on a daily basis. Yes, I'm THAT pi$$ed. Yes, really.

To be honest, I'm not much good at actual coding (apparently I have the dumb and I can't brain as soon as anything concerning classes and objects is involved), but I'm certainly interested in testing anything that would rid me of any remnants of that ghastly Gnome3 UI. I thought Mint Mate would be it - ha-ha yeah right. Not Mint's fault but still. Really just writing this to add one more voice to the disgruntled chorus, and my admittedly insignificant support behind what you are trying to achieve. Just let you know there are others annoyed enough to care...


Welcome to the forum @Wooloomooloo !
I predict that you're the first of many to seek an outlet to express your horror at these changes in MATE in the latest Mint. I certainly don't think you're being overly dramatic - I think there will be a range of reactions from apathetic to mildly annoyed to outraged.
We're a particularly vulnerable group of users in this situation too - we're quite likely to have chosen MATE as a way of keeping a stable, no-nonsense desktop for years to come. I'd imagine that we're generally people who opt for LTS distros and only upgrade when we have to (actually in my case I did it at a moment of feeling a bit daring and part of me wishes I hadn't)... So despite this whole CSD thing in GNOME being 'hot' back in 2018 we are only just discovering it in 2020 and I'm sure there's many folks who won't find out until maybe 2023 when 18.04 reaches its end of life.
We're already two years past when this all happened in the GNOME world and that's practically a whole lifetime in the fast-paced world of Linux development.
One of our hardest challenges will be having to approach a multitude of developers who, two years ago responded to an almost evangelical movement from GNOME that got them to rewrite their UI the GNOME way, and now convince them that it was the wrong decision whilst trying to calmly and patiently explain why it's taken so long for anyone to notice the problem.
I can't wait to see what STLWRT from @gordon looks like but I can't help being a little skeptical that no matter how good it is, it many not be possible to degrade nicely from CSD to a classic menu bar when the items aren't in any logical order in the code - I'll reserve judgment until I try it but I'm also considering that fixing this may require other action - lobbying the GNOME Devs would seem logical but they're so devout to the way of the great GNOME that convincing them to change some of the fundamental new principles in GTK3/4 to accommodate non-GNOME users will likely fall on deaf ears.
So then, unless you can persuade the developers of the entire ecosystem of applications written in GTK to include support for a forked alternative version which retains classic window decorations and menus, then we're pretty much stuck.

I utterly hate this situation! As a user I feel completely trapped - GTK is the bedrock upon which our entire house of cards is built and it's now having an earthquake :pensive:
There's no easy way out of this corner, but hopefully with enough determination and through either some STLWRT magic (i.e. let them do whatever and we'll hack it back into the shape we want) and/or the power of persuasion (getting GNOME Devs to understand our problem) we will hopefully find a way out of this mess :crossed_fingers: