Ubuntu MATE 18.04 no color tab for theme customization

Hello,

I think that @Unicorn777 is speaking about “Appearance Preferences > Customize Theme > Colours” as this screen capture taken by @wolfman in the fourth post in this thread https://ubuntu-mate.community/t/re-creating-the-classical-ubuntu-orange-theme/3062/4

Sadly, this functionality is gone … no more available.
You need to patch manually the theme to change colors.

Kr

Well…I never did…

I didn’t even know that functionality was available first time around

I wonder if “gnome-color-chooser” might do the trick…

Edit to add…

That would be a no on the Gnome color chooser.

It’s how I used to tweak my themes when it was GTK2

So, I am guessing the migration to GTK 3 is what has done for it

Hello,

I do not know about “gnome-color-chooser”. Thanks @stevecook172001
After some search, there is no GTK 3 version.

But I found this tools which seems to be GTK 2 and GTK 3 compatible.
gtk-theme-config: on launchpad.net
Some screen captures: http://www.webupd8.org

Not tested yet and don’t know if it will work with Mate Theme.

Kr,

1 Like

I installed it. It only sort of half works. But, not really.

Yes, I was referring to Appearance Preferences. I’ll be sure to try out the gtk-theme-config and see if I like it or not.

You mean under 18.04 you can have any color you want provided it’s green? No offense to the devs, but I hate the color green and always change it to grey.

Every time I think of upgrading to 18.04 from 16.04 something comes along that turns me off the upgrade. Why would you get rid of this functionality?

2 Likes

I’m very sad that the Appearance Preferences > Customize Theme > Colors is gone - I’ve heavily relied on that for many years. It’s so much more convenient than having to track down which themes’ files’ code to have to figure out how to edit and install. Please reinstate it or similar functionality. I’m guessing this is an upstream MATE issue, not an Ubuntu MATE one, so maybe I’ll ask them, but not being able to customize colors in an LTS release is disconcerting. I use MATE because I want things to stay the same year after year after year so I can focus on things other than figuring out how to force new tweaks for new glitches (which is what the other desktops impose on you).

3 Likes

Unfortunately, this not even an upstream MATE issue: this is an upstream GTK+ issue… They dropped this functionality entirely, and now they are trying to figure out how to drop themes altogether. Since we are bound to GTK+, we have no say in the matter. We’ve had a few possible solutions being discussed, but they would require a lot more developers/time to make them happen.

1 Like

Drop themes? Whaaaaat?

1 Like

This is a recent example:

https://blogs.gnome.org/tbernard/2018/10/15/restyling-apps-at-scale/

I’ve had conversations with people in the GNOME community and the idea of getting rid of custom themes is sort-of a thing…

2 Likes

Gnome devs making arguments like that would have a lot more credibility if this wasn’t something that has worked for literally decades on dozens of platforms without any problem at all. The fact that they managed to half-ass their code so badly that things don’t work any more in GNOME doesn’t magically turn themes into something “impossible”, and to claim that it does is flat-out dishonest.

I fired up an 18.04 VM today to check if a bug in ffmpeg was fixed in that release, and discovered that the footer bar in caja is using a 6pt font: half the size of any font I have set. How? Why?! Because “GNOME, so @#$% you, user scum”.
The mouse wheel randomly doesn’t work for listboxes: a full sweep might move 3 lines, or 1 line, or not even move at all.
The whole thing is just a broken mess.

vkareh: Given how hostile the GNOME devs are to not just user choice, but code that actually functions correctly at all, why is MATE chasing GTK+ updates? Wouldn’t it be better to just use the version linked with MATE 1.12 or so and stay there, instead of pulling in these horrifically-broken newer versions? Or does that cause DLL hell?

1 Like

It’s the tired old argument usually brought up by misinformed Windows users that Linux is somehow ‘fragmented’ because we don’t all run an identical UI.

It’s rubbish of course and I’m sorry, but I have to say it - The Gnome devs locking everything down annoys the hell out of me and totally goes against the whole philosophy surrounding open source and freedom of choice.

One of the major strengths of Linux IMO is that I can make my DE look and behave exactly as I like and I think Gnome is a terrible UI.

2 Likes

Keeping up with newer versions of GTK+ has massive benefits: It’s faster, has HiDPI support, fewer bugs, to name a few. It also has downsides: dropping certain widgets, CSD titlebars, app menus (which are thankfully going away).

Then there’s dependency hell if we don’t keep up. The best solution we’ve found is to fork the deprecated parts of GTK+ that we use into a separate library, and track the rest from upstream. Unfortunately, this requires a lot of work on an already tiny, overworked team, so we haven’t done it yet…

2 Likes

Thanks for explaining, @vkareh. Sounds like a tough situation.

I read that Gnome blog article. I have to admit that I’ve always had my color/theme customizations cause occasional bad indecipherable GUI widgets of too-similar/too-ugly colors on each other, even with GTK-2 (but I never reported bugs to particular apps about it, knowing it was due to my tweaks). GUI design isn’t my specialty so I can sympathize if comprehensive theming really does interfere with apps too much, but I tend to suspect that such a composability issue could be solved well somehow, but that would have to be some whole new different toolkit I guess.

My interest in easy changing of colors is mostly just to be able to change windows’ title bar and border colors semi-frequently, since those are what I like to use to indicate which window has the current focus (I’ve used Dopple for years), and colors and styles I don’t like make it pretty unpleasant. IIUC, this aspect is mostly separate from the theming of the windows’ content so it’d be nice if we could at least be able to customize this via a convenient GUI. Being mostly separate (IIUC), I hope the ability to change titlebar and border colors and styles doesn’t go away if they do away with theming.

[quote=“Bulletdust, post:14, topic:17682”]
One of the major strengths of Linux IMO is that I can make my DE look and behave exactly as I like…[/quote]

Certainly one of the attributes that makes Linux superior IMO. But more than just the GUI, for me it’s really about being able to customize the whole system. Taylor fit it to your needs and desires.

I used to be in that camp. Been really enjoying it as of lately though.

HiDPI support was a must have to keep Ubuntu Mate relevant IMO. Regardless of the trade-offs.

1 Like

The themes I set myself no longer work. The included themes are all either too bright or much too dark. 50% black doesn’t seem to exist. And no way to change that. :-/
That drives me back to version 16.04.

Thanks for the reply. Yeah, I expected dependencies would be the root of the problem.

“Fewer bugs” doesn’t match my admittedly brief experience with it: even utterly basic things are broken. Two easy examples: resizing the Software Updater window doesn’t resize the list it contains; and the mousewheel literally doesn’t work at all about half the time for scrolling a listbox, completely at random.
HiDPI support is obviously hugely important to a subset of users though, so it’s a tough position to be in, and the maintenance burden pretty much forces your hand, as you say. :frowning:

honestly I wonder if MATE will have to leave GTK someday

With 16.04 slowly approaching the point where it's time to start thinking about what to do with my machines (because 20.04 will be the last chance at a better LTS before it EOLs), I thought I'd revisit this.
I remember fixing some bugs in the old Clearlooks XML files way back when 14.04 came out, and I thought I could probably at the very least hack up a script to just generate a new theme file from a template and four user-supplied colors.

After poking around for a bit, I realised something that came as quite a surprise: TraditionalOK and TraditionalGreen had actually removed all the references to VARIABLES in those files and replaced them with LITERALS... :face_with_raised_eyebrow:

I expect there was a good reason for it at the time, but a quick experiment showed that they do in fact still / now work fine in 19.04 when changed back to using variables again, which takes the (user-)workload involved in restoring this basic color-choice functionality from "100s of changes in 1000s of lines" to something much more manageable.

After a few hours of stumbling around trying to figure out how the pieces fit together, I've gotten pretty close to the point where only a few lines need changing to get back all (or nearly all) of the color choice functionality that was lost after 16.04. So now it's trivial for even slightly-savvy users to do, and also simple enough that I might even at some point throw together a little applet to take care of it.

I'll try to finish things up next weekend: if I manage it, I'll post the files here.

One "interesting" problem I've come across is that despite having the controls properly referenced in index.theme the Appearance widget fails to actually load them when you select the theme. You have to use the Customize button and select them manually, whereupon they work perfectly. I'm obviously missing some undocumented trick needed to pull the pieces together (unless it just doesn't work properly when a theme is installed in ~/.themes because there's an absolute file path in there somewhere). If anyone knows what might be causing that, please let me know. Thanks.

  • OK, it works fine if you save it as a new theme and then replace the theme file with the new one. The only differences were that it removed the Comment value and removed the UTF8 line entirely, so it's probably just a garbage parser imploding. Regardless, that piece works nicely too now. :slight_smile:
1 Like

I installed gtk-theme-config, and it works OK for changing colors. For some crazy reason, I'm inordinately fond of the Crux window border, which came with an ugly green color in the the theme. After updating from 16.04 to 18.04, and finding that not only is Crux gone, but so is the color-setting ability for themes, I believe I found Crux theme and window border in a retro corner on github, and gtk-theme-config let me set my preferred (dark red) border.

The reason I went with GNOME instead of KDE years ago was that it seemed to be a highly creative and individualistic project - lots of bugs, and lots of combing and smoothing required, but LOTS OF CHOICES. I'm disappointed to see the creativity and variety going down the tubes, if indeed it goes that way.