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