Re: ENB: Simple design principles for style sheets

[Edward K. Ream]

On Monday, March 12, 2018 at 11:52:05 AM UTC-5, Chris George wrote:
>
> That works, except the file test.leo loads the theme supplied by 
> myLeoSettings.leo instead of the theme contained in the file I am currently 
> working in. eg. Breeze Light Theme - KDE Plasma.leo.
>

Adding support for --theme= command-line would simplify 
your script without resorting to gymnastics.

It's on the list.  I'll push it up.

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: ENB: Simple design principles for style sheets

[Chris George]

That works, except the file test.leo loads the theme supplied by 
myLeoSettings.leo instead of the theme contained in the file I am currently 
working in. eg. Breeze Light Theme - KDE Plasma.leo.

I started out developing *in* myLeoSettings.leo but the new standalone file 
makes far more sense than continuing to do that.

Ultimately I am looking for a way to close and open the current file.

Then the script could simply reload-style-sheets, close current file, open 
current file, and move on.

@language python
import os

c.saveAll()

os.system('konsole -e python3 ~/leo-editor/launchLeo.py 
/home/chris/.leo/test.leo')
# Open ~/test.leo in a separate console.
# t.bat ends with exit so the console closes when I close Leo.
leo_dir = g.os_path_finalize_join(g.app.loadDir, '..', '..')
os.chdir(leo_dir)
# print(g.os_path_abspath(os.curdir))

Chris
 

> On Linux, use something like this:
>
> os.system('x-terminal-emulator -e python launchLeo.py 
> test.leo')
>
> HTH.
>
> 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: ENB: Simple design principles for style sheets

[Thomas Passin]

or, if your app settings on Windows are working right, just

  os.system(r"start C:\path_to_outline\test.leo")

This way, the starting console closes immediately.  True, you have to edit 
the @command ...@key contents if you want to open some other outline 
(workbook.leo might be a good place for this command), but then you don't 
have to find and edit the helper file t.cmd.  

On Monday, March 12, 2018 at 10:54:41 AM UTC-4, Edward K. Ream wrote:
>
>
> ​On Windows I use the following @command node to open a test file. Change 
> it to @button if you like:
>
> @command F5-open-test @key=F5
>
> @language python
> import os
> c.saveAll()
> os.system("start  cmd /c t")
> # Open ~/test.leo in a separate console.
> # t.bat ends with exit so the console closes when I close Leo.
> leo_dir = g.os_path_finalize_join(g.app.loadDir, '..', '..')
> os.chdir(leo_dir)
> # print(g.os_path_abspath(os.curdir))
>
> Imo this is even better than closing and opening your dev .leo file.
>
> F5 saves any work in your dev .leo file and opens the *small* test file 
> in a console.  The console closes automatically when you close the test 
> file.
>
>

-- 
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: ENB: Simple design principles for style sheets

[Edward K. Ream]

On Mon, Mar 12, 2018 at 7:43 AM, Chris George  wrote:

So I guess I am really just looking for the easiest way to close and
> reopen a Leo file programmatically.
>
> An @button would save a lot of time.
>

​On Windows I use the following @command node to open a test file. Change
it to @button if you like:

@command F5-open-test @key=F5

@language python
import os
c.saveAll()
os.system("start  cmd /c t")
# Open ~/test.leo in a separate console.
# t.bat ends with exit so the console closes when I close Leo.
leo_dir = g.os_path_finalize_join(g.app.loadDir, '..', '..')
os.chdir(leo_dir)
# print(g.os_path_abspath(os.curdir))

Imo this is even better than closing and opening your dev .leo file.

F5 saves any work in your dev .leo file and opens the *small* test file in
a console.  The console closes automatically when you close the test file.

Your big dev .leo file never needs to be reloaded.  os.curdir remains
unchanged.

Note: the call to os.system happens after c.saveAll completes fully, so you
are always testing the latest code.  If, say, there is a syntax error in
your python code, loading the test file would fail, but your dev .leo file
remains running.

On Linux, use something like this:

os.system('x-terminal-emulator -e python launchLeo.py
test.leo')

HTH.

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: ENB: Simple design principles for style sheets

[Chris George]

This is how my current workflow goes.

1. Change stylesheet.
2. reload-style-sheets (which I now realize does most of the work by
also saving the file if it is dirty)
3. Closing and reopening the file to see the changes. (verifies that I
haven't broken the css)

So I guess I am really just looking for the easiest way to close and
reopen a Leo file programmatically.

An @button would save a lot of time.

Chris


On Sun, Mar 11, 2018 at 3:59 PM, Edward K. Ream  wrote:
>
>
> On Sun, Mar 11, 2018 at 4:05 PM, Chris George  wrote:
>
>> Would it be possible to program a button to "Reload Stylesheets",
>> close the current file, and then reopen it? I must do this a hundred
>> times a day manually. :-)
>
>
> Why do you want to reload Leo if you reload stylesheets?
>
> 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.

-- 
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: ENB: Simple design principles for style sheets

[Edward K. Ream]

On Sun, Mar 11, 2018 at 4:05 PM, Chris George  wrote:

Would it be possible to program a button to "Reload Stylesheets",
> close the current file, and then reopen it? I must do this a hundred
> times a day manually. :-)
>

​Why do you want to reload Leo if you reload stylesheets?

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: ENB: Simple design principles for style sheets

[Chris George]

Hmmm,

I was considering asking for how to do something similar.

Would it be possible to program a button to "Reload Stylesheets",
close the current file, and then reopen it? I must do this a hundred
times a day manually. :-)

Chris


On Sun, Mar 11, 2018 at 11:02 AM, Edward K. Ream  wrote:
> On Sun, Mar 11, 2018 at 12:45 PM, Edward K. Ream 
> wrote:
>>
>>
>> @button load-ekr @key=F5
>>
>> @language python
>> # Open ekr.leo in a separate process.
>> import os
>> os.system("e")
>>
>> On Windows, F5 will execute e.bat, which opens ekr.leo.  The command runs
>> in the same console as Leo itself, but in a separate process that uses the
>> latest Leo code. Leo remains responsive.
>
>
> Oops.  Leo hangs.  This is opens a new console.
>
> os.system("start cmd /c t")
>
> t.bat ends with the exit command, so the console goes away when I close Leo.
> So now everything happens from Leo itself, and no consoles need to be closed
> by hand afterwards.
>
> 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.

-- 
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: ENB: Simple design principles for style sheets

[Edward K. Ream]

On Sun, Mar 11, 2018 at 12:45 PM, Edward K. Ream 
wrote:

>
> @button load-ekr @key=F5
>
> @language python
> # Open ekr.leo in a separate process.
> import os
> os.system("e")
>
> On Windows, F5 will execute e.bat, which opens ekr.leo.  The command runs
> in the same console as Leo itself, but in a separate process that uses the
> latest Leo code. Leo remains responsive.
>

​Oops.  Leo hangs.  This is opens a *new* console.

os.system("start cmd /c t")

t.bat ends with the exit command, so the console goes away when I close
Leo.  So now everything happens from Leo itself, and no consoles need to be
closed by hand afterwards.

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: ENB: Simple design principles for style sheets

[Edward K. Ream]

On Sun, Mar 11, 2018 at 8:56 AM, Thomas Passin  wrote:

I didn't have too much trouble finding color constants per se.
> ​...​
> But colors look different depending on their surroundings, and I had to do
> a lot of trial and error to hit on ones that worked *and* were distinct
> enough from other syntax colors you might find in a page of code.
>

​Here's a trick I use all the time.  During testing I reload a *small* leo
file, running in another process.  It typically takes just a few keystrokes
to load this.  Not perfect, but the test file could have the syntax
coloring "template" as the selected node, so you can see your results in
context.

Just now I saw that I could speed this process further.  I created the
following @button node as a *common* @button node in myLeoSettings.leo.
That is, it is a child of the @buttons node.

@button load-ekr @key=F5

@language python
# Open ekr.leo in a separate process.
import os
os.system("e")

On Windows, F5 will execute e.bat, which opens ekr.leo.  The command runs
in the same console as Leo itself, but in a separate process that uses the
latest Leo code. Leo remains responsive.

The /wait option to os.system would wait for the command to finish, but I
see no reason to want to do that.

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: ENB: Simple design principles for style sheets

[Thomas Passin]

I didn't have too much trouble finding color constants per se.  I would do 
a web search for, say, "color #553399", and that would show me the color.  
There are also on-line color pickers.  But colors look different depending 
on their surroundings, and I had to do a lot of trial and error to hit on 
ones that worked *and* were distinct enough from other syntax colors you 
might find in a page of code.

That's why the PyScripter way works well.

On Sunday, March 11, 2018 at 8:45:04 AM UTC-4, Edward K. Ream wrote:
>
>
> On Monday, March 5, 2018 at 10:14:00 PM UTC-5, Edward K. Ream wrote:
>>
>> "...EditPlus (Windows only) has a listbox of syntax element names, and 
>> when you choose one it shows you the foreground and background color, which 
>> you can then change using a standard Windows color selector.
>> ​
>> Leo definitely should do at least this much, and to the dropdown list we 
>> can add the foreground/background colors for Leo's various panes, buttons, 
>> etc."
>>
>
>
>

-- 
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: ENB: Simple design principles for style sheets

[Edward K. Ream]

On Sat, Mar 10, 2018 at 7:06 PM, Thomas Passin  wrote:

>
> One more reason I found it hard to adjust the colors is that so many of
> the syntax colors have those JEdit names, like "literal2_color".  What the
> heck does that map to?
>

​These map directly to the constants defined in each .py file in the
leo/modes folder.  There is a script to generate these .py files directly
from the jEdit .xml syntax coloring files.

The code in leoColorizer.py uses these name to init various data
structures.  The actual colorizing code knows nothing *directly *about the
names, but the names are bound (in the modes/*.py files) to arguments to
the pattern matches in leoColorizer.py.

In short, these names can't be changed.

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: ENB: Simple design principles for style sheets

[Edward K. Ream]

On Sat, Mar 10, 2018 at 7:19 PM, Thomas Passin  wrote:

PyScripter displays a small code example that contains most of the code
> structures that get touched by the syntax colorer.  If you click on one of
> them, a picklist scrolls to that element, and the color chooser gets
> populated with the corresponding color, including its symbolic constant
> name, which is shown in an edit box.  You can either pick form a color
> chart or type in a new color.  It's a pretty nice system, and you can see
> clearly which syntax element you are working with.
>

​Very cool.​

​Not sure how to do this.​

>
> EditPlus (Windows only) has a listbox of syntax element names, and when
> you choose one it shows you the foreground and background color, which you
> can then change using a standard Windows color selector.
>
​
Leo definitely should do at least this much, and to the dropdown list we
can add the foreground/background colors for Leo's various panes, buttons,
etc.

Leo's present themes probably already define the color constants needed to
do this easily.  As Terry says, reload-settings would then show the
results.​
​​
​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: ENB: Simple design principles for style sheets

[Terry Brown]

On Sat, 10 Mar 2018 17:06:24 -0800 (PST)
Thomas Passin  wrote:

> One more reason I found it hard to adjust the colors is that so many
> of the syntax colors have those JEdit names, like "literal2_color".
> What the heck does that map to?  If I could have made a change,
> reloaded the settings, and immediately seen the result, I would
> probably have stayed with it longer.

Good point, I've never understood all the numbers, although I wonder if
for example comment1, comment2, comment3, comment4 relative to
different parts of a comment, like

/* this is a delimited comment */

maybe it can color the delimiters different, and of course some
languages have two comment delimiters, // and /* */

Anyway I did just do a test and found that I could just change a
setting (all four comment colors, as it happens), do
reload-all-settings, deselect and reselect a node with code, and see my
changes immediately.  Still far from smooth, but at least no restart.

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: ENB: Simple design principles for style sheets

[Thomas Passin]

PyScripter displays a small code example that contains most of the code 
structures that get touched by the syntax colorer.  If you click on one of 
them, a picklist scrolls to that element, and the color chooser gets 
populated with the corresponding color, including its symbolic constant 
name, which is shown in an edit box.  You can either pick form a color 
chart or type in a new color.  It's a pretty nice system, and you can see 
clearly which syntax element you are working with.

EditPlus (Windows only) has a listbox of syntax element names, and when you 
choose one it shows you the foreground and background color, which you can 
then change using a standard Windows color selector.  It's been too long 
since I used Jedit and I don't remember how they do it.  Notepad++ has much 
the same, but you can have a different  set of syntax colors for each 
programming language if you want..

PyScripter's way is best, though, because you can see the color in a coding 
context as you are making your changes.  It's probably quite a bit trickier 
to get working right, though!

On Saturday, March 10, 2018 at 4:05:08 PM UTC-5, Edward K. Ream wrote:
>
> On Sat, Mar 10, 2018 at 8:58 AM, Thomas Passin  > wrote:
>
>> I just went through a really painful experience when I adopted a dark 
>> theme.  
>>
>
> ​I agree with Terry, this is excellent feedback.  Here are some ideas.
>
> *Color samples directly in Leo*
>
> Understanding colors is always going to be a chore. But here are a few 
> ideas.
>
> 1. Try Leo's show-color-wheel command.
>
> 2. Here's how to see a sample of the defined color in the VR pane:
>
> @color dark-base0 = #fdffdd
>
> Body:
>
> @language md
> div#bg {background:#fdffdd}
> 
> 
> 
>
> Voila, the VR pane contains a color swatch!
>
> I shall do this for all the standard color definitions in leoSettings.leo 
> and in theme files. A color;; abbreviation could be used, but in this case 
> cut/paste will be good enough
>

-- 
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: ENB: Simple design principles for style sheets

[Thomas Passin]

On Saturday, March 10, 2018 at 1:18:38 PM UTC-5, Terry Brown wrote:
>
> On Sat, 10 Mar 2018 06:58:42 -0800 (PST) 
> Thomas Passin > wrote: 
>
> in 5.7, LeoSettings has (at least) four dark themes: "base dark", "windows 
ekr dark", "leo_dark theme 1", and "leo_dark theme 2".  I tried them all, 
and found "base dark" to be the easiest to understand and modify.  I 
probably should have derived a modified theme instead of changing some of 
the colors in the base dark these, but I didn't understand quite how 
everything worked so I took the easy way out.

One more reason I found it hard to adjust the colors is that so many of the 
syntax colors have those JEdit names, like "literal2_color".  What the heck 
does that map to?  If I could have made a change, reloaded the settings, 
and immediately seen the result, I would probably have stayed with it 
longer.  But, at least on my system, I had to restart Leo each time.  A 
mapping description would have been very helpful.

My system is Windows 10, 64-bit Python 2.7, Leo 5.7b2.
 

> > I just went through a really painful experience when I adopted a dark 
> > theme.   
>
> I think this is good feedback.  Although I wonder if you're talking 
> about one of the old themes or one of the new ones, for which I assume 
> the default syntax colors are visible - not quite sure how far out the 
> door the new themes are to be honest. 
>
>
>

-- 
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: ENB: Simple design principles for style sheets

[Edward K. Ream]

On Sat, Mar 10, 2018 at 8:58 AM, Thomas Passin  wrote:

> I just went through a really painful experience when I adopted a dark
> theme.
>

​I agree with Terry, this is excellent feedback.  Here are some ideas.

*Color samples directly in Leo*

Understanding colors is always going to be a chore. But here are a few
ideas.

1. Try Leo's show-color-wheel command.

2. Here's how to see a sample of the defined color in the VR pane:

@color dark-base0 = #fdffdd

Body:

@language md
div#bg {background:#fdffdd}




Voila, the VR pane contains a color swatch!

I shall do this for all the standard color definitions in leoSettings.leo
and in theme files. A color;; abbreviation could be used, but in this case
cut/paste will be good enough.

*Simplifying style sheets*

This is an ongoing project.  Just today I realized (Doh) that QTreeWidget
is a subclass of QTreeView.  As a result, all css for QTreeWidget can be
eliminated in my personal css.

The goal is to use as *little* css as possible.  Again, I have just put
this into practice today, and shall update the two example themes soon.

> I think this might be something that people like Ed don't appreciate
enough:  most of us aren't familiar with the details of this machinery, and
it doesn't seem to be explained well anywhere findable when we want it.

I too forget details.  Everything I do aims at making things as simple as
possible.  This is the third major iteration in designing themes.  Things
seem to be getting a bit better.

Making themes standalone .leo files should help considerably.

I'll continue to work on this project until no further simplifications are
apparent.

Thanks for your comments.  We all have trouble understanding what Leo can
already do.  Color swatches are a cute touch and would not have happened
without you.

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: ENB: Simple design principles for style sheets

[Terry Brown]

On Sat, 10 Mar 2018 06:58:42 -0800 (PST)
Thomas Passin  wrote:

> I just went through a really painful experience when I adopted a dark 
> theme.  

I think this is good feedback.  Although I wonder if you're talking
about one of the old themes or one of the new ones, for which I assume
the default syntax colors are visible - not quite sure how far out the
door the new themes are to be honest.

Regardless, I'd point out that we have a mechanism that's *supposed* to
help with the "find the lever that adjusts X" problem.  The 

  Settings -> Edit Settings

menu tree is supposed to do exactly that.  Right now I would guess it's
not tuned for the new themes, and was never fully fleshed out for the
old themes, but I think it can help with these issues.  We should also
make invoking a color picker on a @color node, and a font picker on a
@font node, easier - there are some button scripts or something
somewhere that do that, but nothing the leaps out and offers to be
helpful.

So I guess I think it will be worth seeing how helpful the Settings ->
Edit Settings menu can be with the new themes.  I think it will be
possible to tune it to the specific settings used by a specific theme,
although of course the more themes share common settings names for
things, like @color body-text-foreground and so on, the less tuning
will be required.

To be clear, I don't think Settings -> Edit Settings can be fairly
evaluated right now, but once the dust settles on the new themes, let's
see what it can do.

Cheers -Terry

> The existing ones that are in leoSettings were unusable,
> because too many of the syntax colors were unreadable against the
> dark background. I've gotten it working more or less to my
> satisfaction (there's one color that's still too dark, but it's too
> painful for me to find and change).
> 
> I spend many hours trying to figure it out and track down the colors
> and what they affected.  For every change, I had to restart Leo
> because reloading the styles and settings didn't seem to do a
> complete job.
> 
> My main problems were these:
> 
> 1. I couldn't always tell what color on the display corresponded to
> which color name.  For example, what syntax color is used for
> triple-quoted text?  And is there a difference between triple quoted
> with double or single quotation marks?
> 
> 2. I had trouble threading through from @color-name to the color 
> specification, because they wren't linked in some easy-to-find way.
> 
> 3.  I found it hard to know which settings affected the display pane
> colors and which affected the syntax coloring colors.
> 
> It's possible that I might get very familiar with these things and
> get more efficient at it.  But most of us will only do this once or
> twice ever, so even if we get good at it, we'll forget how before we
> do it again.  I think this might be something that people like Ed
> don't appreciate enough:  most of us aren't familiar with the details
> of this machinery, and it doesn't seem to be explained well anywhere
> findable when we want it.
> 
> Contrast this with my experience in going through the same process - 
> tweaking a dark theme - with PyScripter.  It was still painful, but
> there is a good color picker, a dialog with symbolic color roles and
> names, and the colors take effect right away.  There is still have
> some ambiguity between a theme and specific syntax colors, but it was
> way easier and far less painful than with Leo.
> 
> On Tuesday, March 6, 2018 at 9:27:16 AM UTC-5, Terry Brown wrote:
> >
> > On Tue, 6 Mar 2018 07:58:33 -0600 
> > "Edward K. Ream" > wrote: 
> >  
> > > ​status_bg_color.  I don't remember exactly.  But the name,
> > > whatever it is, tells us exactly *nothing* about what the actual
> > > color is, and that, and only that, is what is important in the
> > > css.   
> >
> > I think what matters is the color's role, not the actual color
> > itself. Themes are usually built from a relatively small palette of
> > carefully picked colors that play well with each other.  Each color
> > has a specific role withing that palette.  solarized makes the set
> > seem bigger than usual because it's really two palettes, one dark
> > and one light, combined. 
> >
> > It's better to define the css in terms of semantic names like
> > error_fg and info_fg than to have to remember you're using
> > solarized-red (or was it solarized-magenta) for errors and
> > solarized-yellow (or was it solarized-green) for info. items. 
> >
> >
> >  
> 

-- 
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: ENB: Simple design principles for style sheets

[Thomas Passin]

I just went through a really painful experience when I adopted a dark 
theme.  The existing ones that are in leoSettings were unusable, because 
too many of the syntax colors were unreadable against the dark background.  
I've gotten it working more or less to my satisfaction (there's one color 
that's still too dark, but it's too painful for me to find and change).

I spend many hours trying to figure it out and track down the colors and 
what they affected.  For every change, I had to restart Leo because 
reloading the styles and settings didn't seem to do a complete job.

My main problems were these:

1. I couldn't always tell what color on the display corresponded to which 
color name.  For example, what syntax color is used for triple-quoted 
text?  And is there a difference between triple quoted with double or 
single quotation marks?

2. I had trouble threading through from @color-name to the color 
specification, because they wren't linked in some easy-to-find way.

3.  I found it hard to know which settings affected the display pane colors 
and which affected the syntax coloring colors.

It's possible that I might get very familiar with these things and get more 
efficient at it.  But most of us will only do this once or twice ever, so 
even if we get good at it, we'll forget how before we do it again.  I think 
this might be something that people like Ed don't appreciate enough:  most 
of us aren't familiar with the details of this machinery, and it doesn't 
seem to be explained well anywhere findable when we want it.

Contrast this with my experience in going through the same process - 
tweaking a dark theme - with PyScripter.  It was still painful, but there 
is a good color picker, a dialog with symbolic color roles and names, and 
the colors take effect right away.  There is still have some ambiguity 
between a theme and specific syntax colors, but it was way easier and far 
less painful than with Leo.

On Tuesday, March 6, 2018 at 9:27:16 AM UTC-5, Terry Brown wrote:
>
> On Tue, 6 Mar 2018 07:58:33 -0600 
> "Edward K. Ream" > wrote: 
>
> > ​status_bg_color.  I don't remember exactly.  But the name, whatever 
> > it is, tells us exactly *nothing* about what the actual color is, and 
> > that, and only that, is what is important in the css. 
>
> I think what matters is the color's role, not the actual color itself. 
> Themes are usually built from a relatively small palette of carefully 
> picked colors that play well with each other.  Each color has a 
> specific role withing that palette.  solarized makes the set seem bigger 
> than usual because it's really two palettes, one dark and one light, 
> combined. 
>
> It's better to define the css in terms of semantic names like error_fg 
> and info_fg than to have to remember you're using solarized-red (or 
> was it solarized-magenta) for errors and solarized-yellow (or was it 
> solarized-green) for info. items. 
>
>
>

-- 
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: ENB: Simple design principles for style sheets

[Edward K. Ream]

On Tue, Mar 6, 2018 at 8:27 AM, Terry Brown  wrote:

I think what matters is the color's role, not the actual color itself.
>

I am going to reply to this and Offray obliquely in another thread.

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: ENB: Simple design principles for style sheets

[Offray Vladimir Luna Cárdenas]

Hi,

I agreed with Terry on this. One thing is trying to change themes and
other to write them. I general I find that going to a Leo file and start
to write it and saving as a way to expose the "end user" to the
customizations in not friendly. The buffer and menus should provide one
command/click operations to make this possible and in the case of
themes, hopefully with some preview for available themes (as happens in
most desktop environments with Linux distributions) or a quick refresh
that reflects the change, but can be undone easily. Something similar
needs to happen with plugins installation. I think that Atom and others
has a lot to teach us in the front of usability for changing appearance
and behavior of the coding environment without editing explicitly any
config file or going into nested nodes/properties of them. All this
should be underlying infrastructure, generally invisible and only
available on demand.

Cheers,

Offray


On 06/03/18 08:06, Terry Brown wrote:
> On Tue, 6 Mar 2018 04:02:45 -0800 (PST)
> "Edward K. Ream"  wrote:
>
>> - Assume devs and users will want to change css nodes *first*.
> I guess we'll have to agree to disagree on this point.  Most apps.,
> when the user wants to change a font size, presents the user with a
> number to change.  Requiring instead that they edit a headline that
> looks like this:
>
>   @string font-size = 12pt
>
> is already making Leo less friendly to non-coders.  Requiring that they
> edit CSS without messing up the syntax is even more coder centric.  And
> I know you can just copy by example for the syntax, but it's amazing how
> hard people seem to find that.
>
> Maybe fonts are a poor example because they're the one case where you
> accept settings are needed, but it's true of whatever - colors - most
> apps. off a color dialog, but Leo wants you to edit CSS and understand
> color naming?  Actually I think Leo can offer a color dialog for
> editing color settings, not sure.  Again, settings being simpler, *for
> the user*, than CSS.
>
> Finally if two level settings are annoying while developing a theme, it
> would be easy to write a command to dereference the selected text in
> the log, so you can see what it is.
>
> 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: ENB: Simple design principles for style sheets

[Terry Brown]

On Tue, 6 Mar 2018 07:58:33 -0600
"Edward K. Ream"  wrote:

> ​status_bg_color.  I don't remember exactly.  But the name, whatever
> it is, tells us exactly *nothing* about what the actual color is, and
> that, and only that, is what is important in the css.

I think what matters is the color's role, not the actual color itself.
Themes are usually built from a relatively small palette of carefully
picked colors that play well with each other.  Each color has a
specific role withing that palette.  solarized makes the set seem bigger
than usual because it's really two palettes, one dark and one light,
combined.

It's better to define the css in terms of semantic names like error_fg
and info_fg than to have to remember you're using solarized-red (or
was it solarized-magenta) for errors and solarized-yellow (or was it
solarized-green) for info. items.

It was a long lamented shortcoming of WWW CSS that it didn't support
variable substitution, so that for example you had to write

p.content { color: black; }
div.note { border-color: black; }

... plus dozens of other references to black, and then when you want to
change some, you can't use search and replace, and what people really
wanted to be able to do was write

div.note { border-color: var(--main-bg-color); }

which could be changed once in one place.

> Btw, I am running my tests with Python 3.6.3, PyQt version 5.6.2.  If
> this is broken there is not much Leo can do about it.

Well, I agree it's an upstream problem, but also one that shows zero
sign of getting fixed :-/ so we might have to not use ~=, which is very
annoying, design wise.

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: ENB: Simple design principles for style sheets

[Edward K. Ream]

On Tue, Mar 6, 2018 at 7:45 AM, Terry Brown  wrote:

Well maybe we're not talking about the same thing.


​I agree.
​


> To me, two level
> ​ ​
> setting based stylesheets are needed if the user is to be able to tweak
> themes by changing settings.  I want them to be able to see a setting
> like
>@color theme_highlight_fg = @solarized-orange
> and change it to
>@color theme_highlight_fg = black
>

​I think this is the essence of our disagreement.

What, exactly, does theme_highlight_fg mean, abstracted from the css?  I
say, basically nothing.  And if it did mean something, it would be
difficult to say what it means that would be more clear than actually
tweaking the css.

Imo, the goal of "tweaking" themes this way is misguided.  For sure it will
obscure the css.

Imo, it would be better to base a new theme from an old one by using the
user style sheet.  Don't remember its name. This way the tweaks are
expressed as css, without indirection and without fuss.
​


> it makes no sense to change
>
>@color solarized-orange = #ffaa22
> to
>@color solarized-orange = black
>

​I agree. That's a recipe for instant confusion and lasting maintenance
nightmares.

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: ENB: Simple design principles for style sheets

[Edward K. Ream]

On Tue, Mar 6, 2018 at 7:28 AM, Terry Brown  wrote:

​> QLineEdit#status2[style_class ~= 'info'] {
> background: @blah_blah_blah1;
> color: @blah_blah_blah2; ​

Still disagree - blah_blah_blah isn't a reasonable example.


​No.  It is precisely reasonable.  That's the whole point.
​


> What did
> ​ ​
> it really say?


​Something like ​

​status_bg_color.  I don't remember exactly.  But the name, whatever it is,
tells us exactly *nothing* about what the actual color is, and that, and
only that, is what is important in the css.

Btw, I am running my tests with Python 3.6.3, PyQt version 5.6.2.  If this
is broken there is not much Leo can do about it.

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: ENB: Simple design principles for style sheets

[Terry Brown]

On Tue, 6 Mar 2018 07:24:42 -0600
"Edward K. Ream"  wrote:

> > is already making Leo less friendly to non-coders.  Requiring that
> > they edit CSS without messing up the syntax is even more coder
> > centric.  And I know you can just copy by example for the syntax,
> > but it's amazing how hard people seem to find that.
> 
> ​This is a completely separate issue.  I am talking about creating
> understandable style sheets in the present environment.​

Well maybe we're not talking about the same thing.  To me, two level
setting based stylesheets are needed if the user is to be able to tweak
themes by changing settings.  I want them to be able to see a setting
like
   @color theme_highlight_fg = @solarized-orange
and change it to
   @color theme_highlight_fg = black

it makes no sense to change

   @color solarized-orange = #ffaa22
to
   @color solarized-orange = black

partly because defining orange as black is just weird, but more because
it's bound to have broader effects than intended.

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: ENB: Simple design principles for style sheets

[Terry Brown]

On Tue, 6 Mar 2018 05:09:48 -0800 (PST)
"Edward K. Ream"  wrote:

> This simple description results from *eliminating* four @color
> settings. The old way was something like this:
> 
> QLineEdit#status1[style_class ~= 'info'],
> QLineEdit#status2[style_class ~= 'info'] {
> background: @blah_blah_blah1;
> color: @blah_blah_blah2;
> }
> 
> QLineEdit#status1[style_class ~= 'fail'],
> QLineEdit#status2[style_class ~= 'fail'] {
> background: @blah_blah_blah3;
> color: @blah_blah_blah3;
> }
> 
> :-)
> 
> The old way *obscures* these settings! We don't know what colors the 
> "blah_blah_blah" settings mean!

Still disagree - blah_blah_blah isn't a reasonable example.  What did
it really say?  @theme_error_color?  @theme_highlight_color?

I don't think a theme author *must* organize their themes that way, but
I think it's perfectly reasonable that they do so.  Again it would be
trivial to write a command that prints something like

@theme_highlight_color
@solarized-orange
#ffaa22

in the log when run with "@theme_highlight_color" selected.

Also as far as I know the ~= operator isn't working in PyQt5 >= 5.8

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: ENB: Simple design principles for style sheets

[Edward K. Ream]

On Tue, Mar 6, 2018 at 7:06 AM, Terry Brown  wrote:

>
> > - Assume devs and users will want to change css nodes *first*.
>
> I guess we'll have to agree to disagree on this point.


​I'm not willing to concede this yet.
​


> Most apps.,
> ​ ​
> when the user wants to change a font size, presents the user with a
> number to change.  Requiring instead that they edit a headline that
> looks like this:
>
>   @string font-size = 12pt
>
> is already making Leo less friendly to non-coders.  Requiring that they
> edit CSS without messing up the syntax is even more coder centric.  And
> I know you can just copy by example for the syntax, but it's amazing how
> hard people seem to find that.
>

​This is a completely separate issue.  I am talking about creating
understandable style sheets in the present environment.​


Maybe fonts are a poor example because they're the one case where you
> accept settings are needed, but it's true of whatever - colors - most
> apps. off a color dialog, but Leo wants you to edit CSS and understand
> color naming?  Actually I think Leo can offer a color dialog for
> editing color settings, not sure.  Again, settings being simpler, *for
> the user*, than CSS.
>

​I agree that user commands are a good thing.  That's why, for example, we
have the zoom commands and support for Ctrl-wheel zooming.
​


> Finally if two level settings are annoying while developing a theme, it
> would be easy to write a command to dereference the selected text in
> the log, so you can see what it is.
>

​It's even better not to have to do that, as my recent example show.

My summary of the present situation:

1. The new design rules will simplify creation of style sheets.
2. The new Themes menu will allow user's to change themes more easily.
3. Changing font sizes on the fly is easy enough now, though a bit of an
Easter Egg.
4. Changing default font sizes uses Leo's standard settings mechanism.
Making that even easier is possible.  The code that disables tool-tips
shows how to do this from the gui.

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: ENB: Simple design principles for style sheets

[Edward K. Ream]

On Tuesday, March 6, 2018 at 6:02:46 AM UTC-6, Edward K. Ream wrote:

> The info item #786 Design principles for style sheets 
 [summarizes this 
thread].

It's becoming clearer to me that "indirect css" is just misguided.  An 
example should make this clear.

Here is part of the new, simplified, direct, css node for the status area:

QLineEdit#status1[style_class ~= 'info'],
QLineEdit#status2[style_class ~= 'info'] {
background: @solarized-blue;
color: @solarized-white;
}
QLineEdit#status1[style_class ~= 'fail'],
QLineEdit#status2[style_class ~= 'fail'] {
background: @solarized-red;
color: @solarized-white;
}

This simple description results from *eliminating* four @color settings.  
The old way was something like this:

QLineEdit#status1[style_class ~= 'info'],
QLineEdit#status2[style_class ~= 'info'] {
background: @blah_blah_blah1;
color: @blah_blah_blah2;
}

QLineEdit#status1[style_class ~= 'fail'],
QLineEdit#status2[style_class ~= 'fail'] {
background: @blah_blah_blah3;
color: @blah_blah_blah3;
}

:-)

The old way *obscures* these settings! We don't know what colors the 
"blah_blah_blah" settings mean!

Unlike politicians, I have the luxury of admitting my mistakes.  In fact, I 
am thrilled to see that a scheme that I thought was clever was actually 
really stupid :-)

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: ENB: Simple design principles for style sheets

[Terry Brown]

On Tue, 6 Mar 2018 04:02:45 -0800 (PST)
"Edward K. Ream"  wrote:

> - Assume devs and users will want to change css nodes *first*.

I guess we'll have to agree to disagree on this point.  Most apps.,
when the user wants to change a font size, presents the user with a
number to change.  Requiring instead that they edit a headline that
looks like this:

  @string font-size = 12pt

is already making Leo less friendly to non-coders.  Requiring that they
edit CSS without messing up the syntax is even more coder centric.  And
I know you can just copy by example for the syntax, but it's amazing how
hard people seem to find that.

Maybe fonts are a poor example because they're the one case where you
accept settings are needed, but it's true of whatever - colors - most
apps. off a color dialog, but Leo wants you to edit CSS and understand
color naming?  Actually I think Leo can offer a color dialog for
editing color settings, not sure.  Again, settings being simpler, *for
the user*, than CSS.

Finally if two level settings are annoying while developing a theme, it
would be easy to write a command to dereference the selected text in
the log, so you can see what it is.

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: ENB: Simple design principles for style sheets

[Edward K. Ream]

On Monday, March 5, 2018 at 9:14:00 PM UTC-6, Edward K. Ream wrote:
>
> It's easy to create a stylesheet that quickly becomes overwhelming.
>

I am happy with this post.  However, I've wanted to create an even clearer 
summary.  

The info #786 Design principles for style sheets 
 presents such a 
summary.  Unlike posts here, it is easy to revise the summary. Here is the 
present summary:

- Follow the pattern used in @theme Leo Solarized Dark.
- Assume devs and users understand css.
- Assume devs and users will want to change css nodes *first*.
- Avoid settings wherever possible. This is the *Settings Aha!*
   - Settings must be dead easy to understand, both where defined *and *where 
used.
   - Avoid settings defining two-level @ constants.
 Defining color settings using color names is a benign exception.
   - Optional: Avoid settings used in only one place.
 We could eliminate text size settings for *specific *panes, but that's 
a close call.

The settings Aha! may be controversial, but I am convinced it is valid:

- Settings are *separate *from the css.
  They must be understandable from the css *without *having to look up 
their definitions!
*  The clarity of the css is paramount*.
- We must firmly resist the desire to be clever with settings.
- Dead simple settings imply that new themes must be created by copying old 
themes.
  In fact, this initial extra work is unavoidable, and will start paying 
off almost immediately.

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: ENB: Simple design principles for style sheets

[Edward K. Ream]

On Monday, March 5, 2018 at 9:14:00 PM UTC-6, Edward K. Ream wrote:


> *Corollary 2: Avoid two-level @constants*
>

There is one benign exception to this rule.  All themes will likely define 
@color constants in terms of @ constants for solarized or other colors.  No 
confusion or maintenance problems can possibly arise from this 2-level 
indirection.

As a result, we need the full generality of the constant substitution code. 
But we should use it very sparingly.

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.