On Wed, Sep 17, 2014 at 12:07 PM, 'Terry Brown' via leo-editor <leo-editor@googlegroups.com> wrote:
To start with your last comment: > the rest of your post suggests we're at least facing in the same direction :-) I agree. We are making excellent progress. > Theme stylesheets can be vastly different from @data > qt-gui-plugin-style-sheet. Ok. > I think theme designers should try as much as possible to use existing > (i.e. new) @value names, where relevant @value names exist. Where they > don't, they should be free to invent their own. Yes. > Background: the two components of a theme I can think of > that aren't covered by what we've been talking about so far are (a) a > path fragment used to find theme specific icons etc., and (b) a @bool > indicating whether the theme is "dark" or "light", which can be used by > code to make rendering choices. These are both fairly trivial items. Yes. > The "stylesheet & source" machinery was largely to achieve hierarchical > @data nodes, which we have in core now, a major plus, so some of that > complexity is removed. Oh good. > In myLeoSettings.leo, somewhere under @settings, showing only organizer > nodes for the @values nodes, not the @value nodes themselves: > > @theme default > @bool theme_is_dark = False > theme settings > font settings > color settings > body colors > tree colors > border settings > @data qt-gui-plugin-style-sheet > @theme greens > theme settings > color settings > body colors > tree colors > @theme dark theme > @bool theme_is_dark = True > @string theme_path = leo_dark_0 > theme settings > font settings > color settings > body colors > tree colors > border settings > @data qt-gui-plugin-style-sheet This seems like a natural organization. However, many settings are duplicated. At present, Leo can't honor such duplicate settings. I'll talk about possible solutions below. > So the user has the default theme installed, with modifications from > the "greens" color modifying theme, and then they've installed a dark > theme which is probably overriding most of the other two. I don't see > any problem with this arrangement, apart from keeping the user aware of > what's going on, an perhaps suggesting they move the first two out of > @settings for simplicity. How about a "global" setting that would specify which theme/themes, if any, to use. Something like @data themes, where the body lists the themes in which their stylesheets are concatenated. This instantly will provide safety and flexibility. There are at least two solutions to the problem of duplicate settings in different @theme trees: 1. Namespaces for settings. This would be neat, but it seems like an heroic solution. It would not be easy to do, imo. 2. Scripts (config methods), much like the script in the 'stylesheet & source' node. Here is my present thinking. Suppose, first of all, that Leo's config code initially ignores @theme (singular) trees. This does away with duplicates. Heh, heh. Next, when the configuration code finds the (presumably unique) @themes (plural) node, a new config method, say config.create_theme, would do the following: 1. Find all the @theme trees mentioned in the the body of the @themes node. I see no particular reason to require that all @theme trees be children of the @themes node, though that wouldn't be an odious requirement... 2. For each @theme tree, config.create_theme would a) parse all the "inner" settings in the @theme tree and b) create an **internal theme stylesheet** 3. Create the final themes stylesheet by concatenating all internal theme stylesheets. To summarize, @theme nodes present special challenges because Leo lacks settings namespaces. As a workaround, Leo's config code could ignore @theme trees, while a new create_theme method would compose a theme stylesheet by processing all the nodes mentioned in the body of an @themes node. These are just first thoughts, but they show the problem is tractable, following the ideas behind your theme-creating script. Your comments? 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
