-
Notifications
You must be signed in to change notification settings - Fork 147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Look for dark config within non-dark theme folder #152
Conversation
/usr/share/themes/NAME/Kvantum/NAMEDark.kvconfig/svg This allows themes to ship light and dark in one folder.
What a good idea!
|
Oh, it's more complicated than I thought. Let me explain it: To me, the idea is putting dark themes, alongside their light counterparts, inside light folders, regardless of I'll try to implement the idea but can't promise anything because the needed code might be too complex to be maintainable. Is this essential to your plan? |
It's not essential to my "plan" :-) Just, from a convenience point of view, I think it would make sense for non-Kvantum shipped themes to be self contained. (This pull request does not affect At the end of the day, things work with Not sure why it should affect Kvanum Manager (but I admit I did not check (sorry)). But, from my perspective, if Does this pull request not work as-is ? |
That's good news to me :)
It works only in very special cases. I generalized it but there are still so many cases that should be considered and checked -- when the dark svg file is inside the light folder but the dark config file is inside the dark folder; when the light theme is customized but the dark one isn't, and conversely; etc. Actually, the implementation of multiple installation paths and their relative priorities was complex enough to frighten KDE devs (I told you about that in an email). If it weren't for multiple installation paths, this idea could be implemented almost easily but now, it also frightens a "brave" dev like me ;) |
Well perhaps it should be enforced that the SVG needs to be in the same folder as the config? Why would you have it different? Perhaps because they share the same elements, but in this case just duplicate the SVG. Maybe its time to reduce the complexities of installation paths? e..g just use
Then filename needs to be NAME.svg and NAME.kvconfig in the same folder. When looking for a dark variant, check NAMEDark.svg and NAMEDark.kvconfig in the same folder as the light variant - if both found then use. Else look in the above paths but replace NAME with NAMEDark |
Yes, similar things came to my mind: imposing some limitations on "dark-in-light". In addition to your suggestion, "dark-in-light" may be limited to Anyhow, I'll experiment with the idea and will find the best rules :) |
BTW, thank you for the concept of "dark" in general! Apart from its usage under gnome -- and you know my opinion about gnome ;) -- it's a nice idea. You implemented it mostly; I'll do this part. |
Succeeded in doing it with no limitation; will add a commit after some tests and cleanup. |
Done, without any limitation, in 142ee51 Although the implementation is complex -- especially for Kvantum Manager -- it's maintainable because the logic is as simple as this: for each installation path, independent dark themes take priority over those inside light folders, which should be valid (light) themes. The relative priorities of paths are as before. Will search for and fix possible mistakes later. |
When looking for Dark config (e.g, using kvantum-dark) then also look in /usr/share/themes/NAME/Kvantum/NAMEDark.kvconfig/svg This allows themes to ship light and dark in one folder.