Yesterday I prototyped the Themes menu. With the latest code from the
devel branch you can see the results with these two @button nodes:
@button open-light-theme
c.styleSheetManager.load_theme_file('EKRLight.leo')
@button open-dark-theme
c.styleSheetManager.load_theme_file('LeoBlackSolarized.leo')
You can switch back and forth between them as many times as you like. So it
looks likes everything "just" works, but appearances are quite wrong.
The rest of this post is an ENB (Engineering Notebook) post. Feel free to
ignore, but it is pre-writing for new docs. It also discusses planned
improvements in tooling for themes. See the summary.
*Status*
ssm.load_theme_files reads the theme file correctly using a null gui. It
then computes a *local* settings dict that contains the two stylesheets.
It extracts the stylesheets and applies them. This *mostly* handles
stylesheets correctly. However, *settings that affect stylesheets are not
updated correctly at present*.
*Which settings?*
The present code updates the (local) settings using the *entire* @settings
tree in the theme file. This is wrong. Some settings apply to the theme
*file*, rather than the theme. These settings lie *outside* the @theme
tree. Examples:
@bool minibuffer_find_mode = False # Ensures that the Find Tab is visible.
@bool show-tips = False # Suppresses tips when opening the file.
Loading a theme should not change these settings! So the local settings
should include only settings included in the @theme tree.
*Changing settings*
This is unexpectedly tricky. After computing the local settings, we want
to use *all and only* those settings when computing the stylesheets. How
to do this? We don't want to pollute the code with this consideration.
That is, we want the code to continue to use c.config.get* as before.
The simplest thing that could possibly work may be to use *temporary global
settings*. Something like this:
c.config.save_settings() # Saves previous global settings.
c.config.init_setting(local_settings) # Make the local settings global.
<<Use the temporary global settings.>>
c.config.restore_settings() # Restores the previous global settings.
Finally, we *do* want to update the *old* global settings with the new *local
*settings, so they have effect everywhere. These settings affect syntax
coloring, etc., not just the stylesheets themselves.
But we must update the global settings only *after* computing the style
sheets, so that we are *sure* that the computed stylesheets depend *only*
on settings in the @theme tree of the loaded theme and on *nothing* else.
This detail is worth *any* amount of work because it helps us
long-suffering theme devs. Loading a theme file by itself should show devs
*exactly
the same thing* as loading the theme from the Theme menu. The only way to
ensure that is to be very careful about updating settings.
*Checking style sheets*
Qt whiffs when it comes to checking style sheets. I plan to add syntax
checking logic for computed style sheets. The code will warn about:
- Bad nesting of curly braces and comments.
- @constants within comments and unresolved @constants when all is
completed.
These are all signs of trouble. It might be good to run these checks during
every iteration of @constant expansion.
*Summary*
Updating settings is surprisingly tricky. Doing so properly will show devs
*exactly
*what will happen when their themes are applied. These details are worth
any amount of work.
The code that creates and expands style sheets will soon do sanity checks
on the results. The @constant expansion algorithm will remain unchanged.
It may take a day or three to complete this work. Such work will pay off
handsomely.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
