Re: How did I came across Leo?

[Edward K. Ream]

On Sun, Mar 4, 2018 at 9:18 PM, Matt Wilkie  wrote:

>>
​ ​
@root and Leo's tangle and untangle commands will remain "forever".
​>>​
They are, on purpose, no longer documented, [...]

>
​ ​
I would hope they are documented somewhere though? Perhaps within the code
if no place else.

leoPy.leo#Code-->Core classes-->@file leoTangle.py--><< About Tangle and
Untangle >>

However, this refers to Chapter 4, which no longer exits.

>I imagine a future self...
​​
wondering what it does. ;-)

​There is no reason for you or any dev *ever* to try to understand this
code. Just leave it as it is.

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: Unable to push or pull from devel

[Edward K. Ream]

On Sunday, March 4, 2018 at 4:21:36 PM UTC-6, Edward K. Ream wrote:

> I'll back up recently changed files and do a clean clone.

Done.  It was straightforward.

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: my 2 cents to embedding Leo into other editor or vice versa

[Edward K. Ream]

On Sun, Mar 4, 2018 at 10:56 PM, Matt Wilkie  wrote:

​> ​
My conceptual solution to this was/is "What If Topics Were Folders?"

​I always liked the MacOS scheme of allowing folders to be treated as files
with attributes. But Linux and Windows don't do this, so Leo has to have
sentinel lines.  Except now, with @clean, it doesn't.

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: How to make Outlines which contains images and can display those images?

[Edward K. Ream]

On Sun, Mar 4, 2018 at 4:16 AM, Pal Csanyi  wrote:

> I want to write in Leo editor Outline which will be contains images too
beside text.
> Moreover, I want to can see those images.

​​
This is already possible, in a number of ways.
​

- You can put images of various kinds in @html, @image and @svg nodes.​
​

​  You can put either references or actual sources in @html and @svg nodes.​


-
​ Leo's viewrendered pane (Alt-0) will show actual images.  Like this:

@language md


whatever
​


​#762  says ​
​quickstart.leo & CheatSheet.leo should demo Leo's features​
​, including these.

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.

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.

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

[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

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

#768-new-tree branch ready for preliminary testing

[vitalije]

New branch 768-new-tree 
, related to 
issue #768 is ready for testing.

All but 2 unit tests pass. Those two that fail are not related to the new 
tree code (something about docutils and script controller).

All commands that I can think of that are related to tree seem functional. 
Please report any error. Be careful to save often because code still 
contains lot of assert statements that are meant to hard crash any time 
when something is wrong with the outline data. Lot of them I trust is safe 
to remove, but I'd rather leave them on while testing so that bugs can be 
quicker fixed.
If everything goes well, those assertions should be replaced just with 
warning in log.

Lot of code from leo/plugins/qt_tree has been removed. Hoisting, 
de-hoisting, chapters are functional and new tree handles them very easy. 
Probably lot of code in leoChapters can be simplified by delegating work to 
new tree. 

What I have noticed also is that there are quite a lot of 
c.selectPosition(p) calls in places that I would never expect to see them. 
Some of these calls are duplicated. I believe that the reason for this 
calls was to cause redrawing the outline. However, with the new tree code, 
lot of these calls become unnecessary and even danger. New tree expects 
that after any change in the underlying outline structure (*vnodes), it 
needs to synchronize data and only after synchronization to allow selecting 
position.

Browsing LeoPyRef.leo outline with more than 10.000 nodes is breeze.

There may be still something that is not functional in new-tree branch, 
some command that doesn't properly update tree, but I don't expect anything 
that can't be fixed in a day or so.

Please test and report errors.

Vitalije

-- 
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: #768-new-tree branch ready for preliminary testing

[Terry Brown]

On Mon, 5 Mar 2018 11:25:10 -0800 (PST)
vitalije  wrote:

> Browsing LeoPyRef.leo outline with more than 10.000 nodes is breeze.

Was it a problem before?  Not saying it wasn't ;-), just curious what
you're seeing performance wise.  Do you mean with all nodes expanded?

I know based on how QTreeView (not ...Widget, which is less clear to me)
works, infinite nodes should not be a problem really.

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: #768-new-tree branch ready for preliminary testing

[vitalije]

Comparing to Leo's current implementation.  After expanding large outline, 
Leo becomes less responsive. With new code it is not the case. 

On Monday, March 5, 2018 at 8:57:30 PM UTC+1, Terry Brown wrote:
>
> On Mon, 5 Mar 2018 11:25:10 -0800 (PST) 
> vitalije > wrote: 
>
> > Browsing LeoPyRef.leo outline with more than 10.000 nodes is breeze. 
>
> Was it a problem before?  Not saying it wasn't ;-), just curious what 
> you're seeing performance wise.  Do you mean with all nodes expanded? 
>
> I know based on how QTreeView (not ...Widget, which is less clear to me) 
> works, infinite nodes should not be a problem really. 
>
> 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: #768-new-tree branch ready for preliminary testing

[Terry Brown]

On Mon, 5 Mar 2018 12:12:39 -0800 (PST)
vitalije  wrote:

> Comparing to Leo's current implementation.  After expanding large
> outline, Leo becomes less responsive. With new code it is not the
> case. 

Hmm, I gave it a quick try.

Probably minor, but I see todo.py icons aren't rendering, and
multi-node selection isn't enabled.

Comparing Outline -> Expand All on LeoPyRef.leo on 768-new-tree and
master I expected Leo to get really laggy with the old code, but it
didn't really - new code might have been slightly faster, but nothing
super noticeable.

Not trying to say there isn't a major improvement here (removing code
is an improvement by itself ;-) but wondering if your seeing a bigger
performance boost?  I'm using Ubuntu / Python35 / Qt 5.5

Cheers -Terry

> On Monday, March 5, 2018 at 8:57:30 PM UTC+1, Terry Brown wrote:
> >
> > On Mon, 5 Mar 2018 11:25:10 -0800 (PST) 
> > vitalije > wrote: 
> >  
> > > Browsing LeoPyRef.leo outline with more than 10.000 nodes is
> > > breeze.   
> >
> > Was it a problem before?  Not saying it wasn't ;-), just curious
> > what you're seeing performance wise.  Do you mean with all nodes
> > expanded? 
> >
> > I know based on how QTreeView (not ...Widget, which is less clear
> > to me) works, infinite nodes should not be a problem really. 
> >
> > 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: #768-new-tree branch ready for preliminary testing

[Edward K. Ream]

On Monday, March 5, 2018 at 1:25:10 PM UTC-6, vitalije wrote:
>
> New branch 768-new-tree 
> , related to 
> issue #768 is ready for testing.
>

All of the following must be fixed, at a minimum: 

- In the new code, moving a cloned node around a mostly-collapsed tree is 
noticeably and significantly slower than before.  

- Cloning a node may not immediately set the clone mark in the newly-cloned 
node.

- In some cases, clone a node does not appear to do anything. This might be 
a symptom of data loss.  I didn't risk leoPy.leo to test further.

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.

Python console: equiv for Ctrl-B execute-script?

[Matt Wilkie]

So happy to discover the python console! (courtesy of "show what Leo 
already has" thread).

Does it have an equivalent of the Ctrl-B  command, to send 
from body pane and/or outline to the console?
Copy-paste doesn't work because of line-feeds.

matt

-- 
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: #768-new-tree branch ready for preliminary testing

[vitalije]

> Probably minor, but I see todo.py icons aren't rendering, and 
> multi-node selection isn't enabled. 
>
> Thanks for the report, I didn't use neither todo.py nor multi-node 
selection.  I'll try to fix it.

Comparing Outline -> Expand All on LeoPyRef.leo on 768-new-tree and 
> master I expected Leo to get really laggy with the old code, but it 
> didn't really - new code might have been slightly faster, but nothing 
> super noticeable. 

 
I can't say that I see big speed improvements. New code is not yet 
optimized because there are no proper notifications from the model. Vnodes 
don't report any activity on them and in many cases when it is not clear 
what exactly has been changed, safest thing to do is to redraw lot of 
nodes. I am working on this issue too. Making vnodes able to emit 
notifications to all interested parties about what exactly has changed will 
greatly reduce amount of unnecessary redrawing and that is where I expect 
greater speed boost to come. 
 
Thanks for testing.
Vitalije

PS: I won't be able to work on this in the next two days

-- 
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: #768-new-tree branch ready for preliminary testing

[vitalije]

Ok. I'll look at it on Thursday. 

On Monday, March 5, 2018 at 9:41:53 PM UTC+1, Edward K. Ream wrote:
>
> On Monday, March 5, 2018 at 1:25:10 PM UTC-6, vitalije wrote:
>>
>> New branch 768-new-tree 
>> , related to 
>> issue #768 is ready for testing.
>>
>
> All of the following must be fixed, at a minimum: 
>
> - In the new code, moving a cloned node around a mostly-collapsed tree is 
> noticeably and significantly slower than before.  
>
> - Cloning a node may not immediately set the clone mark in the 
> newly-cloned node.
>
> - In some cases, clone a node does not appear to do anything. This might 
> be a symptom of data loss.  I didn't risk leoPy.leo to test further.
>
> 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: #768-new-tree branch ready for preliminary testing

[Terry Brown]

On Mon, 5 Mar 2018 12:45:47 -0800 (PST)
vitalije  wrote:

> Making vnodes able to emit 
> notifications to all interested parties about what exactly has
> changed will greatly reduce amount of unnecessary redrawing and that
> is where I expect greater speed boost to come.

This sounds like it's relevant to
https://github.com/leo-editor/leo-editor/issues/465
although actually that issue has less relevant discussion than I
thought.

Briefly, for the leo-edit-pane (LEP)project
https://github.com/leo-editor/leo-editor/issues/778

I added a simplistic signal manager
https://github.com/leo-editor/leo-editor/blob/master/leo/core/signal_manager.py

which is currently emitting a signal used by LEP
https://github.com/leo-editor/leo-editor/blob/master/leo/core/leoNodes.py#L2550
from vnodes on body text changes.

Although I'm wondering if more of this approach is used it would be
better to switch to https://pypi.python.org/pypi/blinker

I vote against Qt signals because I could see this architecture wanting
to work in non-Qt contexts.

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.

ENB: Simple design principles for style sheets

[Edward K. Ream]

It's easy to create a stylesheet that quickly becomes overwhelming.

This week, for the first time ever, I have created a style sheet this is 
easy to understand and will be easy to change in the future. And today, 
also for the first time, I see clearly the principles involved. Several 
Aha's and corollaries have emerged today in discussions with Terry.  This 
post summarizes them:

*Aha 1: Start with the css*

The guts of any theme is the @data qt-gui-plugin-style-sheet tree. It 
should organized this way:

1. Most css nodes should describe a single area of the screen. 
2. Conversely, *everything* relating to a screen area should reside in a 
single node.

This organization may seem obvious, but older themes did not always follow 
it.  Putting "everything in its place" means that *css nodes contain all 
the @constants related to a screen area*.  This is a big advantage of the 
new scheme.

*Aha 2: Use only "obvious" settings*

Settings should mean something *independently* of how those settings are 
used in the @data tree. The Leo Solarized Dark theme uses only these 
settings:

- Syntax coloring settings. Their meanings are clear. They are necessary, 
but they are not used in the @data tree.

- Font settings. These have obvious meanings. They are the font family, 
sizes, and styles for the body, log and tree panes, and for general text 
areas. Because their meanings are obvious, they can be changed without 
worrying where in the @data tree they are used.

- Color settings. All such settings have clear meanings.  *There are no 
"general" color settings!*

- Settings related to plugins, especially the bookmark plugins. These are 
not so easy to understand, but people can search for them if they like.

- Gradients. These are utility constants. The only design choice is whether 
to use them or not.



*Aha 3: Be wary of using constants that appear only once*The meaning of 
constants is *given by the css*, so turning them into separate settings may 
just obscure what is going on.  The settings in Aha2 are benign exceptions 
to this rule.

*Corollary 1: Resist the temptation to be be clever with settings*

Trying to be clever can instantly create massive confusion. For example, 
the the solarized light and dark themes will differ in "just a few" 
foreground/background colors. Suppose we just create a few settings that 
encapsulate those difference and use those *new *settings instead of the 
actual solarized color names.

This might work, but a search for @solarized- shows that the Solarized Dark 
theme uses almost *all* of the solarized base colors.  Thus, these is *no 
way* to describe how the theme uses those colors 

*except by looking at the css.*In fact, creating another level of 
redirection of @ constants will make things much *harder *to change.  This 
is a crucial point, born out by past painful experience.  In the new 
scheme, if I want to change some region of the screen I just go to the 
corresponding css node and change the desired *one-level* @ constant.  *This 
can not have any other side effects.*

In contrast, using another level of @constant indirection will create css 
that is difficult to understand in the moment, and impossible to remember 
for more than a few hours.  Furthermore, two-level @constants make changing 
css nodes much more risky.  So we have just "proved"...



*Corollary 2: Avoid two-level @constantsCreating new style sheets*

Following these principles means that creating a Solarized Light theme from 
the existing Solarized Dark theme will require an initial examination of 
*all* the (copied) css nodes.  That's a *good* thing.  Real choices have to 
be made for each area. That can't be helped. The solarized base colors have 
meaning *only* in the context provided by the css, so we must examine each 
css node in turn. Pretending otherwise is a *huge* mistake.

This initial extra work (perhaps aided by find/replace) will immediately 
start to pay off. Tweaking css is *much *easier if we confine ourselves to 
one-level @ constants. No confusion. No side effects. Nothing difficult to 
remember.

*Summary*

These principles show how to create *maintainable *stylesheets. They are 
the simplest thing that could possibly work.  Imo, they are the *only* 
thing that work well. They are a huge improvement over previous efforts.

When we follow these principles we can tweak css without understanding 
arcane constants. We can change css without fear of causing unintended 
(cascading!) side effects.

When creating a new theme, we must change one-level @ constants "by hand", 
or with search/replace. This "extra" work is easy. Any mistakes can be 
easily fixed *locally.* The result is a stylesheet that is maintainable 
from the get go.

These Aha's have implications for the Themes menu, but that's another post.

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 a

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.