On Wed, 04 Dec 2013 11:05:29 -0500 Jacob Peck <[email protected]> wrote:
> My only suggestion is that the theming code is tweaked to allow @data > qt...stylesheet (both of 'em) allows << references >> and @others. This > might be non-trivial, but organizing stylesheets as a Leo tree would be > fantastic for maintainability reasons, as well as making the information > contained therein more easily accessible to adventurous souls! This is what the dark theme achieves with a button script that glues the tree-ified form back together, but certainly just using @others would be more consistent. Do we need both @others and << references >>? Hopefully there's a simple call to get the text from a node that accounts for both @others and << references >>, so maybe it doesn't matter. Cheers -Terry > -->Jake > > On 12/4/2013 11:00 AM, Terry Brown wrote: > > On Wed, 4 Dec 2013 04:10:03 -0800 (PST) > > "Edward K. Ream" <[email protected]> wrote: > > > >> Terry continues to do excellent work with style sheets. Alas, I often find > >> myself confused about them. > >> > >> Here, I'll summarize the pros and cons of style sheets, and throw out an > >> alternative for discussion. > > So, that's not really an alternative :-), it's what we're getting > > close to having with the latest code. > > > > Current trunk works like this: > > > > Ordinary Leo @settings, specifically @color and @string > > are used to specify colors, font names, font sizes, etc. > > > > What is different from other uses of @settings uses but not, I think, > > difficult for newbies to grasp, is that you can use other settings to > > specify a setting's value, e.g. > > > > @color solarized-red = #ffee00 > > @color foreground-color = black > > @color foreground-color-body = @foreground-color > > @color foreground-color-log = @foreground-color > > @color foreground-color-tree = @solarized-red > > > > Bear in mind that the newbie pathway to these will be a > > menu ...Settings->Colors menu item which takes you to an organizer node > > which explains what kind of values you can use (black or #1234ed etc.) > > > > For newbies / non-technical users, that's it, stop reading, you're > > done. No mention of stylesheets. You use the ...Settings->Colors menu > > item, you see some settings, edit them, and hit the reload style button. > > > > There's still some clean up to do, but that's how the current code's > > supposed to work, and that seems to embody your alternative quite well. > > > > Clean up is a mixture of replacing remaining literal constants (10px, > > '#fde264', etc. in the stylesheet with a @<identifier> and putting the > > @<identifier> in the regular Leo @settings space, and removing > > remaining explicit widget coloring etc. in the code. > > > > And little things like the docs. / instructions in @settings need to > > explain that syntax coloring colors are different, "here's the list, > > edit as needed, use only these color descriptors". > > > > Implementation wise, there's a Qt stylesheet, it contains @<identifer>s > > which are replaced with the corresponding Leo @setting. > > > > Because long pieces of text aren't Leonine, the dark theme uses a tree > > of nodes to author the stylesheet, and glues it together at "compile > > time", i.e. when the user says to, after editing the tree. Because the > > stylesheet only needs to be applied once, this could perhaps be done at > > run time, but this whole tree authoring thing is a separate layer, not > > a big deal. > > > > And as you see with @data qt-gui-user-style-sheet, people who do > > understand Qt stylesheets can do whatever they want. > > > > Also, there's the theme machinery, which basically means someone who > > understands Qt stylesheets writes one to change more than can > > represented with simple constants. What the theme code adds, beyond an > > alternative stylesheet, is a theme name, which can be used to find > > theme specific versions of icons, and also a flag to tell you if the > > theme is dark or light, which might be useful information for > > plugins etc. > > > > Cheers -Terry > > > >> Pros: > >> > >> - [General] Stylesheets are what Qt supports for styling. Therefore, if Qt > >> can do it, a stylesheet can specify it. > >> > >> - [Extensible] Presumably, any future additions to Qt styling will be > >> supported by Qt stylesheets. > >> > >> - [Simple code] This is a relative term ;-) > >> > >> Cons: > >> > >> - [Fragile] Errors in stylesheets can have global, serious, repercussions. > >> > >> Misplace that semicolon? Trouble! Forget that C-style comments don't > >> nest. Big trouble! > >> > >> - [Too big] Stylesheets contain too much. @data > >> qt-gui-user-plugin-style-sheet helps. > >> > >> But not much. For example, print-settings just shows the entire > >> stylesheet, which is no help at all. > >> > >> - [Special case] Stylesheets are unlike any other Leo settings. > >> > >> I ask myself, can we get the pros without the cons? > >> > >> The general strategy that I would like to discuss here is this: > >> > >> 1. Use "normal" settings for all aspects of appearance covered by the > >> existing style sheet: fonts, sizes, colors. > >> > >> This is the way Leo used to specify these settings. Like:: > >> > >> @font tree-font > >> @color headline-background > >> @color selected-headline-background > >> @color edit-headline-background > >> @color edit-headline-selection-background > >> ... ETC!! > >> > >> 2. Code in qtGui.py would translate those settings into style sheets. > >> > >> 3. Provide an "escape" stylesheet, perhaps just @data > >> qt-gui-user-plugin-style-sheet, that would allow *any* stylesheet tweaks to > >> be added on "last". > >> > >> Yes, this would entail a lot of tedious coding in qtGui.py. And there > >> might even be technical difficulties that wouldn't be easy to solve. > >> > >> But imo, the present scheme is too difficult for everyone (including me, as > >> recent discussions on #leo have shown.) > >> > >> It seems too much to expect newcomers to Leo to handle stylesheets > >> smoothly. > >> > >> Your comments, please, Amigos. > >> > >> 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/groups/opt_out.
