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!

-->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.

Reply via email to