Pluma - Ignoring the user's color scheme?

Does it still default to its Dark theme, unlike literally every other package, and ignore the user's color scheme? It would be good to fix that before 19.10 if it hasn't been sorted out already. (I can't find a record of it, but it's very late here so apologies if I simply missed it).

I'm not sure this is a bug but more like a feature (not sarcastic !)

If you open Pluma's preferences (edit, preferences) and then the font and colors tab you'll have a list of available themes for the app.

The default Pluma theme, Ambiant-MATE, is described as "a dark theme to match Ambiant-MATE".

So it looks like devs intentionally opted for a dark theme even though the Ambiant-MATE desktop theme is a light one.

You can switch the theme there to a light one like Radiant-MATE.

You can find additional themes online (look for 'Gedit themes') and add them effortlessly in the font and colors preferences.

If you want to set a a light theme directly after install, just add gsettings set org.mate.pluma color-scheme Radiant-MATE to your post-install script and forget about it.

1 Like

Well, speaking of Pluma... I've installed Geany long ago and selected it as the default app for texts. And never felt any regret for that.

Jep, I use Geany too (though that's partly because of an issue with VirtualBox and GFVS) - but that's not the point here, and neither is Utsuro's workaround. The OOB experience is "this is Stupid and Broken and Wrong", and it is.

That sub-theme description is simply not true. It DOESN'T match, which is the whole point, and even if users actually want a dark theme (and sure, some do: I used one for a decade) they're still more likely to want it across the whole system, not have some apps one way and some the other. Pluma's job, especially as the default editor, is to respect whatever theme the user chooses. That's half of what themes are for! :slight_smile:

Having one app randomly be different to EVERYTHING else doesen't just look ugly and unpolished: it looks like (and is) a defect, and it's a genuine annoyance because it not only give a bad experience but it also pushes the responsibility for correcting it onto users, when it's not their fault that it's broken.

Maybe this will help clarify WHY it's so wrong, for people who don't understand why this matters (i.e. "It's just one app", or "well you can just add Thing X to the post-install script that you don't have on a Live USB", etc) ...
Say the default system theme is Dark, and the user explicitly changes it to a Light one. Pluma is still using its Dark theme. That alone is flat-out broken. Now imagine that every other app is just as defective. After choosing your Light theme, you have to change the theme in Pluma as well. And then in Caja. And then in Terminal. And then in the Notes applet. And then in Writer. And then Calculator, and so on. Pretty sure you've got the idea by now. :slight_smile:

MATE shouldn't be putting the burden on every single user to have to go and fix the thing themselves just because the app chooses to behave badly.

Would you mind filling a bug report (or feature request) on launchpad? Pluma doesn't have the capability of automatically changing its theme based on the desktop theme (for example, I use Solarized and wouldn't want it to change whenever I change from Ambiant to Menta). But maybe if the pluma themes could respect the desktop's dark variant, that would be a great feature worth adding.
Marco just very recently got this feature a few weeks ago, so up until then this wouldn't have been possible, but maybe it could be now! Who knows! :wink:


re Launchpad - done.

Pluma is something of a special case, in that (thanks to the disease of syntax coloring) it does have a "need" (tho only VERY "sort-of") to have its own themes beyond the system theme. But that absolutely in no way excuses it from at least STARTING with a theme that matches the rest of the system, nor does it excuse it from following the system theme for the elements that ARE shared.

I thought about this a bit last night, and the "real" answer to the problem is "simple", but also multipart, and probably involves more work than the overloaded devs can find time for. (and unfortunately i'm not really in a position to help out ATM either).

At the most basic level, Pluma needs to respect the FG & BG of the theme: not doing that is a defect, plain and simple. But to really do everything IDEALLY, both it and the system need to "know" if a theme is considered Dark or not.

To take a simple example (which, amusingly, is one that Pluma actually gets "wrong" right now) we can examine how it "copes with" an ini file. Using the "Classic" theme, sections are dark-reddish, keys are dark green, and values are flourescent pink (oops!). (Except for when the syntax colorer fails because it doesn't recognise something as a keyword or a literal, in which case they're in black, but that's different problem).

If it behaved properly and you chose a dark theme, the dark elements there would lose most of their contrast and you'd have to change something in Pluma itself - which basically means someone has to make a separate theme for it that's also dark. Again, annoying and a waste of time for both developers and users, but not a big deal if "it's only one app"; but similarly a nightmare if it's EVERY app.

If the system had a way to tag a theme AS "Dark" though, via a key in the theme file, Pluma could trivially promote the colors to high-intensity in that case. But that means exposing that knowledge and then adding the capability to understand and respond to it sensibly to Pluma and any other such apps that have a legitimate reason to CARE about it. (Though 99%+ don't genuinely have one, so at least it's not a sweeping issue).

So yeah - not DIFFICULT, by any means, but somewhat far-reaching, which is never ideal for a resource-poor team.

I see your points, and a lot of this makes sense.

That a pluma theme is miscalibrated with regards to its own colors is the theme's problem, not pluma's.

Here's what we need, in my opinion:

  • a way for the desktop to understand variants (this is now done on marco 1.23)
  • a way for pluma to know which desktop theme variant is active
  • a way for themes to identify themselves as light/dark (and/or to have a variant defined)
  • a toggle on the pluma settings as to whether it should follow theme variants (this part is important)
  • changing the default theme to suit

How does this sound? Anything you would add/remove/change?


That a pluma theme is miscalibrated with regards to its own colors is the theme's problem, not pluma's.

Agreed. I just assumed the Pluma themes were part of the Pluma package.

a way for the desktop to understand variants

Depends a bit on the meaning of "understand" in this context, but yes. (The WM / theming code doesn't actually have to know the MEANING of the value, just that such a key exists and be able to provide that KV to apps.
(And if the theme handling is something super-primitive like "The current theme file is X, go read it yourself" (I've seen worse... :P) then the WM doesn't actually need to be involved at all).

#2 and #3, jep.

a toggle on the pluma settings as to whether it should follow theme variants (this part is important)

jep (mostly). I was going to cover that in the previous post, but as you've noticed by now I tend to ramble as it is, so I deferred it. :slight_smile:
I think the toggle is probably better as "Follow THEMES, period" though. Saying "Use some parts of the theme but ignore other parts" is a bad move: it opens a can of worms that inevitably leads to "I want This exception for Theme X, and That one for Theme Y", and so on.

#5, jep.

You've added the only piece I deliberately skipped (it's not actually REQUIRED for the approach to work, but it's absolutely something that it SHOULD have in an ideal scenario) so if something's still missing now it's because I haven't realised it yet. Which is certainly possible, but when the idea hit me it "felt right", so I think it's probably very close even if so. I'm a big fan of "as simple as possible, but no simpler" - especially when I'm asking someone else to do the actual work (sorry about that: I just don't have the time right now).

I've often noticed Pluma dark theming... That's right.
And having read this thread I've launched Pluma... and voila! It obeys my custom theme (in ~/.themes) . What a surprise!

1 Like

I experience this problem daily as I switch between the Ambiant and Ambiant-Dark every morning and evening. In addition to changing the global theme in the Apperance, I have to change the background in Pluma and MATE Terminal so they match the background color in the rest of the apps.

Pluma I can understand, because that's just plain broken (or "special", if you prefer). The terminal though should be using the theme colors unless you've actually told it not to: I just checked here, and mine correctly responds to theme changes. Have a look at the Colors tab in Profile Preferences and make sure you're not overriding them.

arQon, I don't want to hijack this thread which is about Pluma, but could you confirm that your terminal doesn't behave this way?
MATE Terminal > Edit > Profile preferences > Colors > enable "Use colors from system theme"
Apperance > select "Ambiant-MATE" or "Radiant-MATE"
Expected: bright background in terminal
Actual: dark background in terminal

Selecting other bright themes in Apperance (Menta, BlueMenta, GreenLaguna, Traditional*, HighContrast) gives a bright background in Terminal, so it's not that I'm overriding.

Also, selecting "Radiant-MATE" in Pluma's settings gives it a bright background, not dark as in Terminal.

Wow - you're right. When I tested mine before that last post, it was by changing from my theme to TraditionalOk, and seeing the Terminal background change color. Since that does work, the problem you have must be that the terminal is being given a custom color scheme by the Ambiant-MATE theme itself.

If you look at /usr/share/themes/Ambiant-MATE/gtk-3.0/apps, you can see a custom file for gnome- terminal in there, which does indeed force it to off-white on off-dark. Seems odd that would affect the MATE terminal, so I tried renaming that file then selecting the theme, and the terminal was still broken, so it looks like that's just leftover cruft that should have been removed a few years ago. (Or, it could be that, and I just don't see it because this machine is on 16.04, i.e. GTK2).
There's also an override in the gtk2 dir. I think that's enough places for you to start experimenting with. :slight_smile:

TL;DR though: those themes are broken: probably deliberately, since quite a few people prefer dark terminals, but broken from your perspective. I'd suggest just copying them to your home dir and fixing them.

Just to finish with the terminal issue.

Edit: /usr/share/themes/Ambiant-MATE/gtk-3.0/apps/mate-applications.css
and set background_color and color to your liking, here:

window.background.mate-terminal vte-terminal {
    -TerminalScreen-background-darkness: 0.95;
    /* background-color: #373633; */
    background-color: #ffffff;
    /* font color*/
    /* color: @dark_fg_color; */
    color: #000000;

No offense, but that's clearly the wrong way to do things.

All that does is continue the mistake that caused your problem in the first place. Literally the point of themes is that applications don't randomly choose their own colors, but take them from a single source instead. IOW, that section shouldn't be edited, it should be deleted outright.