On Tue, 7 Mar 2017 16:13:49 -0600 "Edward K. Ream" <[email protected]> wrote:
> The present (accurate) comment is the following: > > In order for theme settings to take effect, you may need to disable > > existing `@color` and `@data qt-gui-plugin-style-sheet` nodes in > > myLeoSettings.leo. Do this by deleting them or moving them out of > > the @settings tree. > > This is unacceptable. It's terribly confusing for me, and I wrote > the settings code. Which setting takes effect? The first one, or the > last? I don't see how this is in anyway specific to themes. It's always potentially confusing to know which of Leo's @settings takes effect, should you have more than one value defined for a particular @setting. > Worse, how do we save/restore settings when switching themes? It's a > nightmare. > > I see no way to switch between settings, except by using completely > distinct @settings trees (disabling the unwanted ones). But in that > case, there is no way, (except by using clones) of sharing common > settings. > > Instead, isolating settings to @constants nodes looks like the > simplest thing that could possibly work. The previous system worked until it was broken by refactoring. > I'm not sure I have conveyed how completely unhappy I am with the > present scheme. It's pissing me off, and it will surely confuse and > terrify newbies. > > > > But that also seems to require iterative substitution. When the > > system was working, it supported both. > > The present code will remain unchanged. New style sheets will > require no further @-substitutions, rendering the present code moot. > > > > Although I disagree with your desire to have static stylesheets(*), > > I don't think it would take any changes to the existing code to do > > that. Just store the output from expand_css_constants() in @data > > qt-plugin-style-sheet, or whatever it's called. > > Out of the question. We aren't going to change things behind the > scenes like that. I think this indicates either a misunderstanding of the code or a miscommunication. If I'm remembering correctly, expand_css_constants() processes all the substitutions. Storing it's output in @data qt-plugin-style-sheet would freeze the them with the definitions present at the time, so the entire theme's represented by a single node, which the user could copy in to their settings. > (*) because static stylesheets force anyone who wants to tweak a > color or > > font size in a theme to recompile the whole stylesheet, vs. just > > changing a single @setting. > > In practice, the new way will be simpler than the old. Just change > the @constants node and press make-style-sheet. The old way already supports exactly that workflow. Just put all your constants in a CSS comment. I think it's much more Leonine to put all your settings in nodes in a subtress. > My offer to take a look at this remains, but I can't do anything while > > you're changing things around. Also, based on the git log message > > experience, I think it would be really useful to have all these > > changes isolated in a branch, so if any rolling back is needed, > > there are interspersed unrelated commits to avoid. > > Yes. I'll create a themes branch next. > > I plan no further changes to the StyleSheetManager class > in qt_gui.py. It will work exactly as before, for compatibility with > existing style sheets (@data nodes). I don't really see how adding a third way to define style sheets (@constants) simplifies things. Cheers -Terry > All further work will likely be confined to leoSettings.leo, > including the new @button node. I'll probably retire themes.leo and > move it to the long-term attic. I'll also eliminate the > open-themes-leo command. > > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
