DrewNaylor / Retiled

An attempt at creating a "desktop" environment mainly for Linux phones and tablets that's similar in function to some parts of Microsoft's Windows Phone 8.x, primarily the Start screen, Search app, navigation bar, Action Center, and the status bar. Development is mainly being done using the PinePhone, so that'll be the main supported device.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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.

DrewNaylor opened this issue · comments

At least it's working so far.

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.