On Wed, 17 Sep 2014 14:10:41 -0500 "Edward K. Ream" <edream...@gmail.com> wrote:
> > 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 [snip] > 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. I'm not sure how much the problem needs solving. Having later in document order override themes earlier in document order seems ok to me, as long as it's clear what's happening. So for example the Reload Styles command could narrate something like this in the log window: Loading settings for "default" theme. Applying changes from "big fonts" theme. Applying changes from "dark 0" theme. Note: effects from earlier themes may be overridden by later themes. The hierarchical menu to present the user with the right tree piece to edit for "colors" or "fonts" could be similarly chatty, and would need to be somewhat clever, it's narration might look something like: Looking for color settings. Color settings found in theme "default". Found theme "big fonts", which does not include color settings. Found theme "dark 0", which overrides color settings from theme "default". Editing color settings in theme "dark 0". Does the .config() machinery allow you to work out where each value was defined? I seem to remember that it does. Hmm, I hadn't thought of concatenating all stylesheets, other than the user stylesheet. It might be a problem if theme A and B stylesheets are conctenated in that order, but B assumes it's modifying Qt's default behavior, not Qt's default behavior + the effects of A. I suspect it might be useful to see how they work in the wild before we try anything too clever. Cheers -Terry > > 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.
