Re: #766: Creating a themes menu

[Edward K. Ream]

​​
On Mon, Mar 5, 2018 at 12:46 PM, Terry Brown  wrote:

I think it's only moot if we decide we don't want to allow users to
> adjust things via @settings, and that editing stylesheets is required
> for tweaking themes.
>

​Lot's of settings still remain.  The ones that I have removed would be
difficult to explain.

I'll go back and take another look.  It might be possible to switch a
solarized light theme to solarized dark just be switching 2 or 3 settings.
The extra level of indirection won't add much more confusion because the
solarized names are already confusing ;-)
​


> Also, although I don't think we should demand that theme authors use a
> particular set of setting names, the more standardization there is in
> that area the more chance users will be able to tweak things like
> foreground color etc. etc.
>

​I'm conflicted about this.  In the present round of development avoiding
indirection seemed to avoid confusion.  I'll see what I think after more
experimentation.  And now is certainly the time for this--I am about to
start work on Leo Solarized Light.

And of course very specific @setting names must be used for body font
> size, or the Ctrl-mousewheel / zoom-in / zoom-out commands will break.
>

​I didn't know that. Happily, zoom-in/out still work, as does ctrl scroll
wheel.

In any case, ​the Font settings will never go away.  They are the first
things people want to change.

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.

Re: #766: Creating a themes menu

[Terry Brown]

On Mon, 5 Mar 2018 12:25:08 -0600
"Edward K. Ream"  wrote:

> ​This will always be a judgement call.  However, this question is
> *almost* moot because in the new scheme my first stop is *always* the
> relevant css node in the @data qt-gui-plugin-style-sheet tree.  This
> ends all confusion!

I think it's only moot if we decide we don't want to allow users to
adjust things via @settings, and that editing stylesheets is required
for tweaking themes.

Also, although I don't think we should demand that theme authors use a
particular set of setting names, the more standardization there is in
that area the more chance users will be able to tweak things like
foreground color etc. etc.

And of course very specific @setting names must be used for body font
size, or the Ctrl-mousewheel / zoom-in / zoom-out commands will break.

Cheers -Terry

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

Re: #766: Creating a themes menu

[Edward K. Ream]

​On Mon, Mar 5, 2018 at 10:42 AM, Terry Brown  wrote:

A reason to retain single use @ constants would be allowing users to
> change things by editing a single setting, rather than having to grok a
> Qt stylesheet.
>

​This will always be a judgement call.  However, this question is *almost*
moot because in the new scheme my first stop is *always* the relevant css
node in the @data qt-gui-plugin-style-sheet tree.  This ends all confusion!

Starting with a *smallish* Qt stylesheet, it is easy to grasp what is
intended. I see all and only the @ constants that apply to that particular
css. From there, it is easy to find @ constants by looking at the theme's
settings tree.  In this case:

   leoSettings.leo#Themes-->@theme Leo Solarized Dark-->
   Settings for Leo Solarized Dark theme

This tree contains just a few, easily understood, categories.

I only understood the importance of *starting with small bits of css* as I
was writing this reply.

Take a look at @theme Leo Solarized Dark.  I think you'll see how simple
everything is.  Of course, css is inherently picky.  Chris George did a
great first draft.  I've done a lot of polishing.

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.

Re: #766: Creating a themes menu

[Terry Brown]

On Mon, 5 Mar 2018 10:42:10 -0600
Terry Brown  wrote:

> A reason to retain single use @ constants would be allowing users to
> change things by editing a single setting, rather than having to grok
> a Qt stylesheet.

Although I think we can also legitimately ask if making themes tweakable
by users is a goal.  A lot of themeable things (browsers, desktops,
mediaplayers) has large libraries of themes, but don't really support
end user tweaks to those themes.  Sometimes you see themes released
with different versions varying only in highlight color (blue / orange /
green), that sort of thing.

OTOH I think we have a system sophisticated enough to make simple
changes accessible to the user, so it seems a shame not to leverage
that, and tweaking font sizes of individual theme elements is a good
accessibility boost.

Cheers -Terry

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

Re: #766: Creating a themes menu

[Terry Brown]

On Mon, 5 Mar 2018 02:51:57 -0800 (PST)
"Edward K. Ream"  wrote:

> 2. With a few exceptions, I eliminated settings used in only one
> place. Now the value of the setting used directly in the css, in the
> proper node. This value might still be an @ constant, but this
> eliminates one level of settings indirection hell.

A reason to retain single use @ constants would be allowing users to
change things by editing a single setting, rather than having to grok a
Qt stylesheet.

I know there are varying views of its utility, but the
Settings -> Edit Settings -> Colors -> etc. menu is supposed to make
this sort of thing easy.

If we at some time decided to have a preferences GUI (which I know
we've steered away from in the past) I think it would use the same
underlying mechanism used by the Settings -> Edit Settings menu, just
in a categorized panel kind of view.  So it would still need the single
use substitutions to insert values into the stylesheet.  This is a bit
tangential, just mentioning it as part of the how to make settings
accessible to newbies issue.

Cheers -Terry

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

Re: #766: Creating a themes menu

[Edward K. Ream]

On Monday, March 5, 2018 at 4:51:57 AM UTC-6, Edward K. Ream wrote:

This a progress report on #766 Create a Themes menu and simplify theme 
> settings .
>

And it was also an update on  #764: Improve the screen shot on Leo's home 
page .

I forgot to mention two, no three, things in the original post.

1. leoSettings.leo contains the new @theme Leo Solarized Dark tree.

2. This theme contains a number of changes from Chris George's original, 
mostly my preferred colors.  It also adds some new syntax-coloring settings 
so that, for examples, the angle brackets in:

   << section name >>

use solarized colors instead of blue, which is nearly invisible.  The new 
screen shot on Leo's home page will show these colors.

3. I updated the VR plugin so it no longer jams it's own style sheet into 
the rendering pane.  Devs should always refrain from dictating how their 
creations will look.  Let the user decide, via themes.

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.

#766: Creating a themes menu

[Edward K. Ream]

This a progress report on #766 Create a Themes menu and simplify theme 
settings .

This post discusses two topics:

- How to create a Themes menu.
- How to make developing themes easier for devs.

I have just partially fixed #780: @tabwidth -2 in @data 
qt-gui-plugin-style-sheet crashes Leo on startup 
.
The crash no longer happens, but imo Leo directives should be removed 
before doing @-constant substitutions. Other than that, the @constant 
machinery will remain unchanged.

*How to create a Themes menu*

An Aha! makes this easy.  The new Themes menu will simply load a *theme 
file* *as if they were settings files*.  Each theme file will be a regular 
.leo file, with an @settings tree containing:

- (Optional) Settings related to syntax coloring.
- (Optional) A single @theme tree.

So a theme file could change to syntax coloring only, or could install a 
complete theme, with corresponding syntax coloring options. Leo should have 
at least the following theme files:

- SolarizedDarkTheme.leo
- SoarizedLightTheme.leo
- LegacyLightTheme.leo
- SolarizedSyntaxColoring.leo
- LegacySyntaxColoring.leo

*How to make developing themes easier for devs*

Chris George submitted a superb new theme for #764: Improve the screen shot 
on Leo's home page .

The following remarks are based on my experiences adapting his theme.  I 
was happy to do this work, because it clarified the issues in creating 
themes.

The @theme tree contained a lot of cruft left over from when themes were 
created by a script.  Such scripts are completely unnecessary now that 
@data nodes can contain a tree of nodes. I reorganized the @theme tree as 
follows:

1. All css relating to a single Leo widget (body, log, tree, etc.) are now 
gathered in a separate child of the @data node.  This avoid duplication and 
confusion.

2. With a few exceptions, I eliminated settings used in only one place. Now 
the value of the setting used directly in the css, in the proper node.  
This value might still be an @ constant, but this eliminates one level of 
settings indirection hell.

The remaining settings in the @theme tree are:

- Settings used in multiple places.  Especially font-related settings, but 
also various @color settings.
- Syntax-coloring settings. These are not used in the @data node.

Theme files will probably contain a copy of the color definitions now in 
leoSettings.leo.

*Summary*

Theme files are .leo files contain an @settings tree for syntax coloring 
and/or themes. Picking a theme will load these files as if they were 
settings files.

Rev b2ed012 adds a disabled @theme Leo Solarized Dark theme that looks good 
on both Windows and Linux.  This @theme node will be the basis of all theme 
files.

@-constant replacement will remain unchanged, but reducing @constant 
indirection is often a good idea.

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.