Skip to content
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

Closed
wants to merge 1 commit into from
Closed

Look for dark config within non-dark theme folder #152

wants to merge 1 commit into from

Conversation

CDrummond
Copy link
Contributor

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.

/usr/share/themes/NAME/Kvantum/NAMEDark.kvconfig/svg This allows themes
to ship light and dark in one folder.
@tsujan
Copy link
Owner

tsujan commented Aug 27, 2017

What a good idea!

setUserTheme() is a little tricky because of 4 installation paths, their priorities and the possibility of missing files.

@tsujan
Copy link
Owner

tsujan commented Aug 27, 2017

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 useDark. However, self-consistency and backward compatibility should be considered. For example, if a dark theme has its own folder, that folder should be picked up. That requires checking for "dark-in-light" places whenever temp doesn't exist... Moreover, a dark theme shouldn't be in a light folder (IMO) if that folder doesn't contain a light theme. And yet, Kvantum Manager may need modification.

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?

@CDrummond
Copy link
Contributor Author

CDrummond commented Aug 27, 2017

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 /usr/share/Kvantum) For instance, most Gtk themes ship the light and dark variant in the same /usr/share/themes/NAME/gtk-3.0 folder. Therefore, it would be nice if all theme authors could ship Gtk and Qt themes in the same folder.

At the end of the day, things work with /usr/share/themes/NAME/ and /usr/share/themes/NAME-Dark/ - so its not essential, just nicer.

Not sure why it should affect Kvanum Manager (but I admit I did not check (sorry)). But, from my perspective, if /usr/share/themes/NAME/ has /usr/share/themes/NAME/Kvantum/NAME.kvconfig and /usr/share/themes/NAME/Kvantum/NAMEDark.kvconfig I would only expect Kvantum Manager to show NAME and not NAMEDark

Does this pull request not work as-is ?

@tsujan
Copy link
Owner

tsujan commented Aug 27, 2017

It's not essential to my "plan" :-)

That's good news to me :)

Does this pull request not work as-is ?

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 ;)

@CDrummond
Copy link
Contributor Author

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

  1. ~/.local/share/themes/NAME/Kvantum
  2. ~/.local/share/Kvantum/NAME/
  3. /usr/local/share/themes/NAME/Kvantum
  4. /usr/local/share/Kvantum/NAME/
  5. /usr/share/themes/NAME/Kvantum
  6. /usr/share/Kvantum/NAME/

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

@tsujan
Copy link
Owner

tsujan commented Aug 27, 2017

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 /usr/share/themes/. I'm pretty sure that Kvantum Manager will need changes here and there.

Anyhow, I'll experiment with the idea and will find the best rules :)

@tsujan
Copy link
Owner

tsujan commented Aug 27, 2017

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.

@tsujan
Copy link
Owner

tsujan commented Aug 29, 2017

Succeeded in doing it with no limitation; will add a commit after some tests and cleanup.

@tsujan
Copy link
Owner

tsujan commented Aug 30, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants