In case my method of loading themes is slow due to reading files, I'll need to somehow construct something in memory that can be referred to by any controls like I did for UXL Launcher. #232
Comments
|
This is really important on the PinePhone as its eMMC is really slow and will make performance worse to keep hammering the disk over and over. Might be able to do a module thing in a QML file like I did for the font stuff so it's shared throughout the program and within the Qt layer rather than having to consult Python. Then the only time the disk will be accessed for theme stuff is whenever the theme changes, and we'll load it in. It would make it easier to deal with theme-related code too, as it would be out of the way of the stuff that does things and won't have to run functions all the time to get the current values. This does mean though that I'd have to write another theme engine, but fortunately it's simpler because all I need is the code to load from storage and place it into the variables in memory. Could probably use Rust actually, that should make it fast enough instead of having to worry my Python would be slow, use a lot of memory, or make things take longer to load. Probably would be an application that gets run and returns JSON through standard out that we'll throw at Qt to store away. Edit: Could probably also just store the theme data in a Python dict and have the code that gets theme data redirect to that data after it's loaded on app startup (would happen before the UI is ready just to be safe; could be slow in Python due to no real async hence my idea for using Rust), then later have it be a Rust library or a program that's called and returns the data if I need more performance. |
|
Maybe if I go the Rust route, I could use configparser (not to be confused with Python configparser): https://docs.rs/configparser/latest/configparser |
|
Wait a minute, should I write a daemon that provides theme data over D-Bus so fewer apps have to access the drive all at once when the theme changes? Or is that too much? The theme change signal would also be sent through D-Bus anyway, but probably when first starting an app it could load directly from the theme file. |
Initial support for different themes. This is an initial implementation of support for themes other than the default dark theme. For now, the themes are in `./RetiledThemes` and the default theme family is `Retiled-Metro`, with its default theme in it being `MetroDark`. You can change the theme that's loaded in the config file, just look for `ThemeFamily` and `ThemeName` (these work using subdirectories). There's also a light theme if you want to use it (`MetroLight`), but it might not be 100% accurate yet (I need to check). I'm planning on allowing themes to be loaded from `/usr/share/themes` and the equivalent folder in the home directory, but I'm not ready to do that yet. When changing the theme in the config file, you'll have to restart any apps that use my theme code, because support for changing themes at runtime isn't implemented yet. The format I chose for the themes is basically like the .desktop spec, but heavily modified where each major component uses its own section, with a details section at the top. Theme families will also get their own file, but that's not implemented yet. I have added theme support to the Settings, Start, and Search apps so far, as well as the Action Center and the compositor (even though I'll switch to being a Look-and-Feel package for Plasma Mobile, I still want to keep the compositor alive for now just in case it ends up being needed). The way I load themes is unoptimized as each property loads the theme file and grabs an item out of it. This will be changed to load the theme into a dict or something at start (and when the theme changes), and each item will consult that dict in memory instead. See also #232. `ThemeType` has been removed from the config file, so I need to figure out a transition thing just in case anyone changed it to `light` to wait for the light theme to be added. The `ThemeType` key in theme files is a similar idea, but used for setting `Universal.theme` instead and may be used for displaying light vs dark themes in a menu. Edit: wait, maybe that would be too much to do. Sorry about going back on this, but I don't really want to add support for `ThemeType` in the config file because it's a lot more work to figure out a way to do it that won't clutter it up. I'll need to otherwise have the Settings app not break the config file when changing values that weren't available before. High contrast themes can also be made using the example light and dark themes as a base. Edit: light theme appbars use RGB 221, 221, 221 for their background according to this SO answer, which converts to `#DDDDDD`: https://stackoverflow.com/a/24015523
At least it's working so far.
The text was updated successfully, but these errors were encountered: