![]() ![]() I think the toggle is probably better as "Follow THEMES, period" though. 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. :P) then the WM doesn't actually need to be involved at all).Ī toggle on the pluma settings as to whether it should follow theme variants (this part is important) (And if the theme handling is something super-primitive like "The current theme file is X, go read it yourself" (I've seen worse. (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. I just assumed the Pluma themes were part of the Pluma package.Ī way for the desktop to understand variantsĭepends a bit on the meaning of "understand" in this context, but yes. That a pluma theme is miscalibrated with regards to its own colors is the theme's problem, not pluma's.Īgreed. So yeah - not DIFFICULT, by any means, but somewhat far-reaching, which is never ideal for a resource-poor team. (Though 99%+ don't genuinely have one, so at least it's not a sweeping issue). 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. 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. 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 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. (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). Using the "Classic" theme, sections are dark-reddish, keys are dark green, and values are flourescent pink (oops!). 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. But to really do everything IDEALLY, both it and the system need to "know" if a theme is considered Dark or not. (and unfortunately i'm not really in a position to help out ATM either).Īt the most basic level, Pluma needs to respect the FG & BG of the theme: not doing that is a defect, plain and simple. 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. 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. 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. 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. After choosing your Light theme, you have to change the theme in Pluma as well. Now imagine that every other app is just as defective. Say the default system theme is Dark, and the user explicitly changes it to a Light one. "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). Maybe this will help clarify WHY it's so wrong, for people who don't understand why this matters (i.e. 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. Pluma's job, especially as the default editor, is to respect whatever theme the user chooses. 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. That sub-theme description is simply not true. The OOB experience is "this is Stupid and Broken and Wrong", and it is. 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. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |