On Fri, Mar 10, 2017 at 8:06 AM, Terry Brown <terrynbr...@gmail.com> wrote:
> > 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. > Well, the work is done. It was straightforward. themes > ... must be able to include arbitrary amounts of their own "Qt-CSS". > Not a problem. > > 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"? > The base theme base won't change, and so neither will the clones of parts of it. > > This seems to imply that all themes need to be kept in sync. and Leo > devs. are responsible for maintaining them > . > > People could contribute any theme they like, organized as they like. But @theme base dark makes it possible to create (and describe) a scheme as small diffs from the base. > > If the new scheme prevents *new* themes from having their own "Qt-CSS" > code, I don't think it's a good idea. It doesn't, as shown in the windows ekr dark theme. > it > > seems a new theme could just break the rule about including a copy of > some common base? Yes it could. > Given that, I'm not really sure what the new scheme > > changes. > It makes it possible to describe new themes in terms of diffs to a quite reasonable base theme. @theme windows ekr dark does exactly that, via the two zz nodes. It's a big improvement. I used this while developing the Linux ekr dark theme. 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.
