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

Themes should allow importing other themes as a base. #236

Open
DrewNaylor opened this issue Jul 13, 2023 · 3 comments
Open

Themes should allow importing other themes as a base. #236

DrewNaylor opened this issue Jul 13, 2023 · 3 comments

Comments

@DrewNaylor
Copy link
Owner

It could get really bad for theme maintenance at some point if it doesn't. I'd need to have a file that says what keys are expected for themes to contain for each version of Retiled, and that would be used for when we load themes where we'll see if a theme has a required key, and if it doesn't, use the theme it imports instead. If that theme doesn't have it, ideally we should keep going until we run out of themes to import from, then use the default value, but I don't know how to reasonably do the recursive import thing so for now I'm going to just do a one-layer import as that's simpler.

So in summary when loading into the dict, we'll check if each key is in the theme, and if not, substitute it with the one it imports or the default value if its import doesn't have it.

I think KDE Plasma has this feature, but I don't remember.

@DrewNaylor
Copy link
Owner Author

DrewNaylor commented Jul 14, 2023

To check if a theme doesn't have a required key, there should be a script that takes the default theme (the dark one) and converts it into minified JSON that we load in to compare the requested theme at runtime. The script would need to be run after adding new supported keys. This JSON only has keys, no values, and values are either filled from the imported theme or the default theme (which should also be loaded at runtime along with the imported theme if it exists but both should be thrown out after we're done loading everything into the dict, because all that remains will be the "compiled" theme consisting of the requested theme and any gaps that were filled in). Maybe there should be support for versioning the theme engine, I'm not sure because that may be a lot more difficult to put into every program.

(The following paragraph was copied into #238 because it needs to be its own issue but I'm leaving it here because it leaves off from the previous paragraph)
What I should do is have a "real" version of shared/reused libraries and just have a script that copies them to each program's libs folder. Then the copies in each folder that aren't the main one would be gitignored. I'd still need to have a message in the readme where it says how to run stuff to run a script to copy the libs into each subfolder. This would also allow me to pull out the settings and theme-related code from each main.py file instead of copying everything every time I make a change. Would also help other developers too, but they'd probably find it easier to just copy the libs folder manually instead of editing the script. I'd also have to change stuff so the path to the themes folder can be modified in case a program is not in my folder, but my goal is to have themes be installed to /usr/share/themes and the home folder version, so I'll need to change my paths when it's ready to be released.

@DrewNaylor
Copy link
Owner Author

Ok that last comment isn't getting the link to #238 correctly even after editing it.

@DrewNaylor
Copy link
Owner Author

I know an easy way to check if a theme has what's needed: load themes in using configparser and check if it has_option and return it, otherwise return the default like I do for loading settings. The default for certain things like theme publisher and copyright would be "unknown" or whatever I do for UXL Launcher Theme Engine/PortableThemeEngine.

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

No branches or pull requests

1 participant