On Wed, 17 Sep 2014 05:52:59 -0500 "Edward K. Ream" <[email protected]> wrote:
> On Tue, Sep 16, 2014 at 7:19 PM, 'Terry Brown' via leo-editor > <[email protected]> wrote: > > On Tue, 16 Sep 2014 17:06:11 -0700 (PDT) > > "Edward K. Ream" <[email protected]> wrote: > > > >> Imo, it's time to simplify how themes get specified, but we'll have > >> to discuss this... > > > > A @theme node, perhaps? :-) > > Yes! Good idea. Yes, more explicit than the current text find. > I know from reading the old "reload" code that it searched for themes > first, and searched for @data qt-gui-plugin-style-sheet nodes only if > no stylesheet & source node is found. I would like to avoid such > logic. > > Happily now that the @data qt-gui-plugin-style-sheet is fully > parameterized, we should only ever need one copy of it. The theme > will simply provide all the settings that modify this style sheet. Theme stylesheets can be vastly different from "@data qt-gui-plugin-style-sheet", which I would consider a theme itself, the "default" theme. It is impossible to fully cover the range of possible customization with settings (@values) alone. > Themes should use the new style sheet: otherwise there will be *two* > sets of style-sheet-related settings floating around, and that will > really cause confusion. So, imo, themes should be defined in terms of > the new settings (and @value) names, not in terms of old @value names. 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. 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. 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. I could see "settings only" themes, which don't supply a stylesheet, only some settings, and "settings and stylesheet" themes, which supply both. But I'm not sure the distinction between them is very important. Setting aside, temporarily, issues of theme management and keeping the user informed, something like this would seem to work quite well to me. 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 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. Out of time, but the rest of your post suggests we're at least facing in the same direction :-) Cheers -Terry > Themes could use a new style sheet, say @data > qt-gui-theme-style-sheet, for selectors not found in @data > qt-gui-plugin-style-sheet. However, I would rather avoid yet another > style sheet if possible. If @data qt-gui-theme-style-sheet contained > just a few selectors they could be made part of the standard @data > qt-gui-plugin-style-sheet. > > My first draft of this reply worried about redundant theme-related > settings, but that's not a big issue because the settings will be > copied to myLeoSettings.leo, *not* leoSettings.leo. > > Still, the user will have to take care to remove all existing > gui-related settings when installing a theme. That should not be too > difficult. BTW, I don't remember which settings take effect when > there are duplicates--the first or the last. Either way will cause > troubles for some users--far simpler if they remove any potential > duplicates. > > In short, copying an @theme node to myLeoSettings.leo, with all its > inner @color, @font and @string nodes, should be be the first step > when installing a new theme. If necessary, an install-theme command > would complete the installation, perhaps with an associated button. > Install-theme would search for a *unique* @theme node in the @setting > tree, and refuse to continue if there are several. > > These are just my first impressions. Your comments, please. > > 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
