Theming and Style memory (started: Progress Bar Bug)

[electricalhog]

I did a local merge of main into theming_style to see if I could get my usual watch configuration to work with the new theming changes. I got it to work with no app loaded, but trying to load level, I came across the error:

Traceback (most recent call last):
File "code.py", line 142, in
File "tg_gui_platform/root_wrapper.py", line 166, in _std_startup_
File "tg_gui_core/root_widget.py", line 86, in _std_startup_
File "tg_gui_core/root_widget.py", line 112, in _build_
File "tg_gui_core/layout.py", line 64, in _build_
File "tg_gui_std/pages.py", line 127, in _build_
File "tg_gui_core/layout.py", line 64, in _build_
File "tg_gui_platform/progress_bar.py", line 73, in _build_
File "tg_gui_platform/progress_bar.py", line 83, in _update_progress
TypeError: 'float' object is not callable

From my testing, the variable progress that was being called had a value 0.0 as set in lines 57 and 65 of progress_bar.py instead of being some kind of stateful object or whatever else it should be.
I think I've seen styling changes work with progress bars so maybe its a me thing.

[TG-Techie]

Looks like I forgot to push a recent change, my bad. Line 83 should be calling self._group.set_progress(clamp(...)) not assigning .progress

[TG-Techie]

Give me a mo to push that change

[electricalhog]

It might be unrelated, but I think the splash screen is broken in the theming branch

[TG-Techie]

It is related, I removed the boot progress bar to reclaim some ram. ProgressBar and Slider now use a Shape-based, custom progress bar.

[TG-Techie]

It could be added back, it'd need to be re-implemented

[electricalhog]

It's fine, the watch is now crazy low on ram. I can't even load an app without removing other features.

[TG-Techie]

Ditto / possible fixes

There are a few things that could be tried to reduce ram usage, like storing the colors and elements as instance variables as opposed to dict items. I think the currently devised theming and style system is like the "platonic ideal" of a style system for TG-Gui but it doesn't fit.

The best approach may be to find a simple subset of the idea that retains the flexibility but reduces the abstraction.

Thoughts

Part of the issue stems from python as a language, since everything is heap-allocated (excluding some Circuitpython optimizations) any action will take referenced memory. This is a tradeoff that some compiled languages don’t have to make, Widgets and Button Styles can be value typed and, in possibility, only take stack space.

A possible fix, but i don’t know

some options to consider would be integrating the ButtonStyle / etc into StyledWidget, so the _style_colors_ and _style_elements_ are declared in the class body.

There are some things that can certainly be preserved from the current branch: some of the ram optimization, the new progress bar, etc.

[electricalhog]

I agree that it definitely needs but be cut down to save ram. I've been daily driving the new theming changes with the level app, but the torch had to be sacrificed and even still it crashes multiple times a day.

[TG-Techie]

I've been having the same experience. However, now having written the theming_style branch most of the modifications were in theming.py... I think the style could be moved into the platform/standard library (which I think should be merged). This may require a patching Container but that shouldn't be an issue.

Possible Next Steps

Excluding the theming and style modifications, I think tg_gui_core is in a pretty stable position. It may make sense to freeze it into the firmware where it is atm. Any bugs we find can be patched using python's magic dynamism.

This would give time to consider more a streamlined approach to styling. I also think separating the core from the std library is a better practice and re-inforces some of the principles in the framework.

Proposeal

What if the next step is to go through the current main and "clean memory house". This could include:

• had rolling drivers
• reducing the number of python modules defined
• possibly forcing users to only import exactly what one needs (Though I don't like that)
• removing the absolute position calculations from Widget as UIKit, QT, etc use relative positioning (probs not necesary)

the only remaining change might be moving the calculation of position and dimension specifiers from _form_ and _place_ into the __call__ sugar

[TG-Techie]

Thoughts?
Your priorities/input would be greatly appreciated, I'm not sure what would be best to prioritize

[electricalhog]

I am very impresessed with the the core and satisfied with it enough to solidify it in firmware. I hope doing so will be the big relief of ram that is needed to properly implement the std library and user apps on top. At the time of posting this I think main is a viable version of the software for the watch, however the features are only limited by system resources and not a lack of core functionality.

[TG-Techie]

glad to hear it! will work on it next.

I think I'm going to remove DimensionSpecifiers as they've yet to be used.

[TG-Techie]

altho they are used for ratio(width + 7) expressions sooooo...... nm, I'll leave it in