![]() ![]() (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 |