On Fri, 10 Mar 2017 02:26:41 -0800 (PST) "Edward K. Ream" <edream...@gmail.com> wrote:
> Note to Terry. You need not be concerned about this. The proposal > does not affect existing users of themes directly, except to clarify > the differences between themes. > > If there is a problem, we could revert just leoSettings.leo. Moving > to a new branch doesn't help because changes to leoSettings.leo > (within Leo) persist when switching branches. As always, if there is > a problem I will be responsible for making things right again. Sure you have to restart Leo if you swap out leoSettings.leo, but a branch is still a convenient container for a set of related changes, not sure I follow the above. > I am about to refactor Leo's the @theme trees in leoSettings.leo into > an unchanging *base *part, and a few *overrides *for each theme. > Themes will be defined by their overrides. As I said much earlier in this discussion, themes can't be limited to a single style sheet and substitutions of font sizes, colors, etc. in that style sheet. They must be able to include arbitrary amounts of their own "Qt-CSS". > A *copy *of each base will be included in each @theme tree. Copies > are required because Leo does not support including one stylesheet in > another. The intention is that base part will *never* change. Of "each base", or "the base"? > *Pros* > > Separating overrides from the bases will make it much clearer what > the differences between themes are. This is a big deal, for both > users and devs. Moreover, If the base ever does need to change, it > will be easier to copy the base tree to all @theme nodes than to make > changes piecemeal to all @theme trees. I've made such piecemeal > changes repeatedly in recent days. It gets old quickly. This seems to imply that all themes need to be kept in sync. and Leo devs. are responsible for maintaining them - I don't think this pattern is seen in other theme collections. > *Cons* > > The refactoring might, by mistake, change the effect of one or more > of the themes. But this will effect only *new* users of themes. Old > users won't be using any of these themes--they'll be using their > previous themes. And even old users might prefer to use the new > themes, since their customizations can be localized. > > *Summary* > > The new @theme nodes will exist only to leoSettings.leo. They will > not take effect unless a user copies an @theme node to > myLeoSettings.leo. > > The refactoring will help both devs and users, including existing > users. The refactoring might, by mistake, change what themes do, but > that should not cause great problems. > > The new scheme will help me *today* when I create @theme Linux EKR > dark. If the new scheme prevents *new* themes from having their own "Qt-CSS" code, I don't think it's a good idea. I'm not sure it does though, it seems a new theme could just break the rule about including a copy of some common base? Given that, I'm not really sure what the new scheme changes. One thing to watch, there's a relationship I can't remember between themes and dynamic font size changing (Ctrl-mousewheel zooming). Cheers -Terry > 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.
