When I apply switch between the Light and Dark variations of the global Breeze themes to, in essence, switch between Dark Mode and Light Mode (as OSes/DEs with less advanced theme engines phrase it) the KCM informs me that it’ll modify configurations which, in actuality, shan’t be modified, because they’re already configured as it intends to modify them.
As an example, if I apply solely the apperance configuration (since that’s what I want):
I would appreciate this being more directly communicated, because it means less verification that nothing I didn’t expect modified during a colouration swap was modified.
Most notably, why would the window decoration style, application style, and splash screen change? I’m switching from Breeze to Breeze, merely with a different colouration.
I realize what the underlying reasons for the current differential implementation are - it doesn’t intelligently verify which preferences shall be modified - but it should. That’s what this idea describes.
Affects:
Colour Scheme
It switches between “Breeze Dark” and “Breeze Light”:
This is quite interesting - when “Breeze”, “Breeze Dark”, and “Breeze Light” all coexist, and applying a global theme informs the user that it shall apply a new Plasm Style, one might expect that it shall choose one of the correlated presets:
The language being simplified is part of the problem… the idea of bringing in the phrases ‘dark mode’ and ‘light mode’ as if we’re all using Android phones goes against the grain, when it’s basically a finely tunable gradient.
From the days of Windows XP (a universally lauded theme, though a little long in the tooth still very useful as a basis for tuning a colour scheme) everyone simply reached for extremes…
I use a different mouse cursor (which is valid for just about all colour schemes, dark or light) and I think the term ‘MODE’ is just basically wrong… unless you’re actually inverting colours in an existing scheme, then it should be ‘Dark Theme’ and ‘Light Theme’.
I agree that checked items should only include new items after applying… though I’d personally prefer the option to (after tuning my settings) save my own Global theme as a default user option in the Global Theme settings window.
This could render all those ‘config saver’ utilities superfluous and bring KDE forward ten years in a single stroke.
I say this because I don’t like either the standard ‘Breeze Dark’ or ‘Breeze Light’ schemes but have several personalised colour schemes - only one of my saved Global themes applies a different icon theme to suit the colours.
I don’t understand. Of course it will, initially inform that it will/might affect those settings.If a user uses default breeze for nearly everything, only a few will be ticked. But if a user uses a custom splash, colorscheme, icon set, application style, window decoration…he’s kinda warned in advance that changing the global to breeze, all his settings could be gone. Then again, I could be missing the point of this post entirely. Personally, I don’t care about a splash screen, I set it once and be done with it, I’m not staring at it all day. As for the rest, all is completely custom and I use as a plasma and icon theme that adapt to the colorscheme. Me too am one of those “extremists” that don’t like breeze. At all.
I agree that perhaps an option to have a save function in terms of your own global theme couldn’t hurt. But, it should be fairly easy to make. A desktop application that does just that. Kinda like a switch for your own custom global theme settings. A bit like that…forgotten the name…anyway, that theme config saver widget.
There are probably other ones but: https://store.kde.org/p/1298955
@ben2talk, I think that that’s worth at least another Brainstorm post if it’s not already been posted or tracked at Bugzilla/Phabricator/GitLab.
I’d not considered what you describe, yet it seems like a self-evident lack now. I’d certainly have appreciated such functionality back when I considered the default themes less aesthetically pleasant (than I do now).
In this case, they are in practice (although not literally in their manually harmonised implementations) children of a single theme which merely differs in the 3 aforementioned aspects:
flowchart LR
C[<b>Breeze</b> <br> <ol> <li>Application Style</li> <li>Window Decorations</li> <li>System Sounds</li> <li>Splash Screen</li> </ol>]
C --> F[<b>Modifications</b> <br> <ol><li>Colours</li> <li>Icons</li> <li>Cursors</li> <li>Plasma Style</li></ol>]
F --> D[<b>Breeze Light</b>]
F --> E[<b>Breeze Dark</b>]
…so switching between them isn’t equivalent to switching between entirely custom themes. Had XP’s theme engine been unlocked by default in user-releases (I recall that it was solely available in a leaked build without modifications to the OS) I would have proposed the same for Windows too.
@dzon, what you describe is what I’m suggesting. However, that’s not the current implementation. Instead, it ticks all.
No - I did play around with Konsave - this Plasma Customization saver saves literally EVERYTHING creating massive backups - not just items necessary for the theme.
Konsave is nice because it is inclusive - if you make a creamy desktop with a creamy light terminal scheme, for example - that will be restored also… but in the end I tend to just stick with switching my colour scheme if I need a quick change (usually due to some software or contrast issue).
O yeah. I don’t need a widget or some saver or whatever. I have a day and night scheme and only need to switch the color. All the rest follows.
And since I’m a lazy bum…
