Re: Update re: new model

[Edward K. Ream]

On Fri, Aug 10, 2018 at 4:47 PM, Terry Brown  wrote:


> textEdited seems to fire on every key stroke:
>

Have you tried the same for the outline editors?

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: Update re: new model

[Edward K. Ream]

On Mon, Aug 6, 2018 at 9:29 PM, Terry Brown  wrote:

Another way to avoid the surprise of finding GUI involvement in a write
> string to file operation would be to make changes to p.h immediate,
> like changes to p.b.  So p.h changes as you type in the headline
> line-edit, then endEditing() wouldn't be needed.
>

Alas, that does not seem possible.  Iirc, no events are generated in the
QLineEdit until the user hits return.  This is what makes the entire
onHeadChanged logic so difficult.

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: Update re: new model

[Terry Brown]

On Mon, 6 Aug 2018 14:48:18 -0500
"Edward K. Ream"  wrote:

> > AttributeError.  Basically it comes down to requiring, or not
> > requiring, the user to do
> > if c.gui:
> >   c.gui.endEditing()
> > (or `c.gui and c.gui.endEditing()`)
> > 
> That's a lot of work, a lot of infrastructure, a lot of constraints
> and extra mental load.  Putting one or more guards in  c.endEditing()
> avoids all that bother.

Another way to avoid the surprise of finding GUI involvement in a write
string to file operation would be to make changes to p.h immediate,
like changes to p.b.  So p.h changes as you type in the headline
line-edit, then endEditing() wouldn't be needed.

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: Update re: new model

[Edward K. Ream]

On Mon, Aug 6, 2018 at 1:13 PM, Terry Brown  wrote:

On Mon, Aug 6, 2018 at 9:09 AM Edward K. Ream  wrote:
>
> > Scripts, plugins and Leo itself should be able to call c.endEditing()
> anytime, anywhere.  Period.  Even if the call does not actually make a lot
> of sense, c.endEditing should recover gracefully from such "misguided"
> calls.
>
> I think there are a couple of subtleties here.  (1) try and find
> another app. that recognizes (app.) global key commands while editing
> in a line edit widget.


Some hacks are needed to make this work, but they are localized.  They do,
however, complicate the init code.

>  It's only because Leo actually allows invoking Save while
> editing a line edit widget that c.endEditing() is needed.
>

That may be true, but I don't think this way.  I just want as much as
possible to work regardless of context.

(2) I think is a design issue.  It's counter-intuitive that writing a
> string to a file should be impacted by GUI state.  Leo doesn't have a
> GUI free layer.


I just want classes (and modules) to be as independent as possible.

leoNodes.py is "gui free".  Almost everything else is concerned with the
gui, in one way or another.

The WrapperAPI class defines the abstract interface for used throughout
Leo's core.  This has (several times) allowed us to change the actual gui
without making any substantial changes to Leo's core.  So the WrapperAPI
could be said to be the text's gui layer.  Imo, it has worked well.

> Then the debate would be whether c.gui should just be None or absent
> in the absence of a gui, so
> c.gui.endEditing() would raise AttributeError None has no attribute
> endEditing, or whether c.gui, when there is no gui, should
> be some clever object that (a) evaluates to None, (b) is callable,
> returning None, and (c) returns itself for any attribute access, so
> that
> c.gui.tree.scrollUp() would silently do nothing instead of raising the
> AttributeError.  Basically it comes down to requiring, or not
> requiring, the user to do
> if c.gui:
>   c.gui.endEditing()
> (or `c.gui and c.gui.endEditing()`)
>

That's a lot of work, a lot of infrastructure, a lot of constraints and
extra mental load.  Putting one or more guards in  c.endEditing() avoids
all that bother.

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: Update re: new model

[Terry Brown]

On Mon, Aug 6, 2018 at 9:09 AM Edward K. Ream  wrote:
>
> On Saturday, August 4, 2018 at 2:39:26 PM UTC-5, vitalije wrote:
>
> > initialization code should be kept free and clean of any gui calls.
> Leo's guiding architectural principle is: There shall be no global 
> architectural dependencies.

> Scripts, plugins and Leo itself should be able to call c.endEditing() 
> anytime, anywhere.  Period.  Even if the call does not actually make a lot of 
> sense, c.endEditing should recover gracefully from such "misguided" calls.

I think there are a couple of subtleties here.  (1) try and find
another app. that recognizes (app.) global key commands while editing
in a line edit widget.  I think Leo's behavior in this respect is very
unusual.  E.g. in any app. try editing the find string (Ctrl-F) and
see if Ctrl-S initiates a save when you're in the find line edit
widget.  Usual behavior is that only Ctrl-A/C/X/V/Z work in line edit
widgets.  But, it's really cool being able to type "tss;;" (my
abbreviation for time-stamp-short) in a headline widget and get
201808. It's only because Leo actually allows invoking Save while
editing a line edit widget that c.endEditing() is needed.

(2) I think is a design issue.  It's counter-intuitive that writing a
string to a file should be impacted by GUI state.  Leo doesn't have a
GUI free layer.  If it did things might be broken up differently:
  c.outline.
  c.gui.

Then the debate would be whether c.gui should just be None or absent
in the absence of a gui, so
c.gui.endEditing() would raise AttributeError None has no attribute
endEditing, or whether c.gui, when there is no gui, should
be some clever object that (a) evaluates to None, (b) is callable,
returning None, and (c) returns itself for any attribute access, so
that
c.gui.tree.scrollUp() would silently do nothing instead of raising the
AttributeError.  Basically it comes down to requiring, or not
requiring, the user to do
if c.gui:
  c.gui.endEditing()
(or `c.gui and c.gui.endEditing()`)

Finally I think the idea that Save (or whatever) should capture the
text of a line entry currently being edited is a bit of a toss up.  If
you're taking notes in an outliner kind of way, I guess it makes
sense.  There might be alternate key-handler patterns that avoid the
issue, although there's still the case of background save events etc.

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: Update re: new model

[Edward K. Ream]

On Saturday, August 4, 2018 at 2:39:26 PM UTC-5, vitalije wrote:

> initialization code should be kept free and clean of any gui calls.

Debatable.

> Either writeFromString must not call gui methods like endEditing, either 
reload_settings, init_env in abbrevCommands must not call writeFromString.

Even more debatable.

> Clearly we should here have two methods:

This crosses the line from debatable to misguided.
 

> def writeFromString(self, root, s, forcePythonSentinels=True, useSentinels
> =True):
> """
> Write a 4.x derived file from a string.
>
> This is at.write specialized for scripting.
> """
> self.c.endEditing()
> # Capture the current headline, but don't change the focus!
> return self._writeFromString(root, forcePythonSentinels, useSentinels)
>
> def _writeFromString(root, forcePythonSentinels, useSentinels):
> at = self; c = self.c
> ... rest of method
>
>
What you are proposing are global constraints on when and where methods are 
called.  To my knowledge, there are *zero* such constraints in Leo.  If 
there are any, then they should be removed.

Leo's guiding architectural principle is: 
*There shall be no global architectural dependencies.*

Scripts, plugins and Leo itself should be able to call c.endEditing() 
anytime, anywhere.  Period.  Even if the call does not actually make a lot 
of sense, c.endEditing should recover gracefully from such "misguided" 
calls.

Typically this involves various guards or other consistency checks.  These 
checks are essential, and they make Leo's code base robust.

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: Update re: new model

[vitalije]

>
> Works for me.  However, the tree widget has a light background, even when 
> using a dark theme.
>

ATM new tree widget uses hard-coded defaults which I defined to look like a 
brand new Leo tree without any user configuration. Other than that I added 
some code to parse global qt stylesheet and collect relevant configuration 
from there. I checked BreezeDarkTheme and it gives almost the same look as 
the original Leo tree. However, the other themes may define values using 
slightly different way and this simple parsing is not good enough. 

I would rather ask theme authors to define all the settings new tree 
understands and uses in a separate style node. They still can use constant 
expansion but parsing would be much easier and with more predictable 
results.
Currently new tree understands and uses:

   - background-color when tree has focus
   - background-color when tree doesn't have focus
   - color:  a text color when tree has focus
   - color: a text color when tree doesn't have focus
   - has-siblings-image: a vertical line signalizing there is a following 
   sibling
   - branch-end-image: a "L" shaped line when this node is the last child
   - branch-more-image: a "|--" shaped line for node which is not the last 
   child
   - open-image: an image signalizing branch is expanded
   - close-image: an image signalizing node has children but it is collapsed

For themes that are part of Leo I can add those settings and perhaps one 
can be added in leoSettings.leo for default configuration when user runs 
Leo for the first time.

That would be simplest thing that could possibly work.

Your thoughts?

Ok.  This is not a revolutionary idea. 
>

No, it is not :-). I just wish it was used more often in initialization 
code.

Note also that if precompiled settings have been used there would be no 
need for abbrevCommands to call writeToString before Leo is fully 
initialized.

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: Update re: new model

[Edward K. Ream]

On Sat, Aug 4, 2018 at 2:39 PM, vitalije  wrote:

>
>> Instead initialization code should be kept free and clean of any gui
>> calls. Either writeFromString must not call gui methods like endEditing,
>> either reload_settings, init_env in abbrevCommands must not call
>> writeFromString.
>>
>> def writeFromString(self, root, s, forcePythonSentinels=True,
> useSentinels=True):
> """
> Write a 4.x derived file from a string.
>
> This is at.write specialized for scripting.
> """
> at = self; c = at.c
> c.endEditing()
> # Capture the current headline, but don't change the focus!
> ... rest of method
>
> Clearly we should here have two methods:
> def writeFromString(self, root, s, forcePythonSentinels=True, useSentinels
> =True):
> """
> Write a 4.x derived file from a string.
>
> This is at.write specialized for scripting.
> """
> self.c.endEditing()
> # Capture the current headline, but don't change the focus!
> return self._writeFromString(root, forcePythonSentinels, useSentinels)
>
> def _writeFromString(root, forcePythonSentinels, useSentinels):
> at = self; c = self.c
> ... rest of method
>
>
> Then abbrevCommands could safely call at._writeFromString instead of high
> level gui method at.writeFromString.
>
> This way lots of other code parts may be freed from guards that are not
> necessary.
>

Ok.  This is not a revolutionary idea.  Commander methods (often delegated
to code in leo/commands/*.py)  are responsible for the entirety of a
command, including gui code, undo, etc., while lower-level methods,
especially in leoNodes.py, are responsible only for Leo's data model.

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: Update re: new model

[Edward K. Ream]

On Sat, Aug 4, 2018 at 2:29 PM, vitalije  wrote:

> Revision  5c8fa20
> 
> contains fix.
>

Works for me.  However, the tree widget has a light background, even when
using a dark theme.

>
> This is a perfect example of the initialization mess.
>
...


> Instead initialization code should be kept free and clean of any gui
> calls. Either writeFromString must not call gui methods like endEditing,
> either reload_settings, init_env in abbrevCommands must not call
> writeFromString.
>

Or an extra guard can be added, as you did, without imposing any global
constraint.

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: Update re: new model

[vitalije]

>
>
> Instead initialization code should be kept free and clean of any gui 
> calls. Either writeFromString must not call gui methods like endEditing, 
> either reload_settings, init_env in abbrevCommands must not call 
> writeFromString.
>
> def writeFromString(self, root, s, forcePythonSentinels=True, useSentinels
=True):
"""
Write a 4.x derived file from a string.

This is at.write specialized for scripting.
"""
at = self; c = at.c
c.endEditing()
# Capture the current headline, but don't change the focus!
... rest of method 

Clearly we should here have two methods:
def writeFromString(self, root, s, forcePythonSentinels=True, useSentinels=
True):
"""
Write a 4.x derived file from a string.

This is at.write specialized for scripting.
"""
self.c.endEditing()
# Capture the current headline, but don't change the focus!
return self._writeFromString(root, forcePythonSentinels, useSentinels)

def _writeFromString(root, forcePythonSentinels, useSentinels):
at = self; c = self.c
... rest of method


Then abbrevCommands could safely call at._writeFromString instead of high 
level gui method at.writeFromString.

This way lots of other code parts may be freed from guards that are not 
necessary.

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: Update re: new model

[vitalije]

Revision  5c8fa20 

 
contains fix. 

This is a perfect example of the initialization mess. From the traceback it 
is clearly that this exception was raised during load of settings. It is 
not possible that user started to edit headline in this stage. And yet 
endEdit is called. Yes, I know this call is made most likely just to make 
sure. But because of this redundant, *just to make sure *call it is 
necessary to put some extra guards in the code that would otherwise work 
without it. And those guards must exist in lots of places just because we 
are reusing same code in initialization as in normal running state.

Instead initialization code should be kept free and clean of any gui calls. 
Either writeFromString must not call gui methods like endEditing, either 
reload_settings, init_env in abbrevCommands must not call writeFromString.

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: Update re: new model

[Edward K. Ream]

On Sat, Aug 4, 2018 at 11:56 AM, Edward K. Ream  wrote:

> Thanks. On a bike ride with Rebecca. Will try later
>

Copied leo/core/leoDataModel.py. Now I get:

>python c:\leo.repo\leo-editor\launchLeo.py --gui=qttabs --gui=qttabs
leo\core\leoPy.leo leo\plugins\leoPlugins.leo
c:\Users\edreamleo\ekr-projects.leo leo\doc\LeoDocs.leo

reading settings in C:/leo.repo/leo-editor/leo/config/leoSettings.leo
reading settings in C:/Users/edreamleo/.leo/myLeoSettings.leo
reading settings in c:/leo.repo/leo-editor/leo/core/leoPy.leo
Traceback (most recent call last):
  File "c:\leo.repo\leo-editor\launchLeo.py", line 8, in 
leo.core.runLeo.run()
  File "c:\leo.repo\leo-editor\leo\core\runLeo.py", line 72, in run
g.app.loadManager.load(fileName, pymacs)
  File "c:\leo.repo\leo-editor\leo\core\leoApp.py", line 2209, in load
lm.doPrePluginsInit(fileName, pymacs)
  File "c:\leo.repo\leo-editor\leo\core\leoApp.py", line 2387, in
doPrePluginsInit
lm.readGlobalSettingsFiles()
  File "c:\leo.repo\leo-editor\leo\core\leoApp.py", line 2151, in
readGlobalSettingsFiles
theme_path = lm.computeThemeFilePath()
  File "c:\leo.repo\leo-editor\leo\core\leoApp.py", line 1795, in
computeThemeFilePath
theme_c = lm.openSettingsFile(path)
  File "c:\leo.repo\leo-editor\leo\core\leoApp.py", line 2113, in
openSettingsFile
c = g.app.newCommander(fn)
  File "c:\leo.repo\leo-editor\leo\core\leoApp.py", line 1539, in
newCommander
return leoCommands.Commands(fileName, relativeFileName, gui,
previousSettings)
  File "c:\leo.repo\leo-editor\leo\core\leoCommands.py", line 79, in
__init__
c.finishCreate()
  File "c:\leo.repo\leo-editor\leo\core\leoCommands.py", line 410, in
finishCreate
c.abbrevCommands.finishCreate()
  File "c:\leo.repo\leo-editor\leo\commands\abbrevCommands.py", line 53, in
finishCreate
self.reload_settings()
  File "c:\leo.repo\leo-editor\leo\commands\abbrevCommands.py", line 67, in
reload_settings
self.init_env()
  File "c:\leo.repo\leo-editor\leo\commands\abbrevCommands.py", line 133,
in init_env
useSentinels=False)
  File "c:\leo.repo\leo-editor\leo\core\leoAtFile.py", line 1695, in
writeFromString
c.endEditing()
  File "c:\leo.repo\leo-editor\leo\core\leoCommands.py", line 3382, in
endEditing
c.frame.tree.endEditLabel()
  File "c:\leo.repo\leo-editor\leo\core\leoFrame.py", line 1359, in
endEditLabel
self.onHeadChanged(p)
  File "c:\leo.repo\leo-editor\leo\core\leoFrame.py", line 1306, in
onHeadChanged
nwt.commit_headline(c.p.h)
  File "c:\leo.repo\leo-editor\leo\core\leoFrame.py", line 2169, in
commit_headline
p.h = h2
  File "c:\leo.repo\leo-editor\leo\core\leoNodes.py", line 3092, in _set_h
val = val.replace('\n', '')
AttributeError: 'NoneType' object has no attribute 'replace'

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: Update re: new model

[Edward K. Ream]

Thanks. On a bike ride with Rebecca. Will try later


On Sat, Aug 4, 2018 at 11:48 AM Terry Brown  wrote:

> On Sat, 4 Aug 2018 10:39:03 -0500
> "Edward K. Ream"  wrote:
>
> > ModuleNotFoundError: No module named 'leo.core.leoDataModel'
> >
> > What should I do?
>
> Is it this, from an earlier post?
>
> "Note, anyone who wants to try this branch, the code needs the latest
> version of leoDataModel.py file in leo/core/ folder. This file can be
> obtained from its repository."
>
> (https://github.com/leo-editor/new-leo-model)
>
> Cheers -Terry
>
> > 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.
>
-- 
--
Edward K. Ream: edream...@gmail.com Leo: http://leoeditor.com/
--

-- 
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: Update re: new model

[vitalije]

Yes it is. Thanks I forgot to put the link.
Vitalije

On Saturday, August 4, 2018 at 6:48:34 PM UTC+2, Terry Brown wrote:
>
> On Sat, 4 Aug 2018 10:39:03 -0500 
> "Edward K. Ream" > wrote: 
>
> > ModuleNotFoundError: No module named 'leo.core.leoDataModel' 
> > 
> > What should I do? 
>
> Is it this, from an earlier post? 
>
> "Note, anyone who wants to try this branch, the code needs the latest 
> version of leoDataModel.py file in leo/core/ folder. This file can be 
> obtained from its repository." 
>
> (https://github.com/leo-editor/new-leo-model) 
>
> Cheers -Terry 
>
> > 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: Update re: new model

[Terry Brown]

On Sat, 4 Aug 2018 10:39:03 -0500
"Edward K. Ream"  wrote:

> ModuleNotFoundError: No module named 'leo.core.leoDataModel'
> 
> What should I do?

Is it this, from an earlier post?

"Note, anyone who wants to try this branch, the code needs the latest
version of leoDataModel.py file in leo/core/ folder. This file can be
obtained from its repository."

(https://github.com/leo-editor/new-leo-model)

Cheers -Terry

> 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: Update re: new model

[vitalije]

File leoDataModel.py is not added to Leo yet, because it is in another 
repository.
You should obtain the latest version of this file and put it in the 
leo/core/ folder.

Having same file in two different repositories would make confusion and 
unnecessary merge conflicts, so, I prefer not to add it to Leo until it is 
stabilized.

Vitalije

ModuleNotFoundError: No module named 'leo.core.leoDataModel'
>
> What should I do?
>
> 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: Update re: new model

[vitalije]

> Must say I'm surprised by the "draw the tree yourself" approach, but 
> will see how it pans out. 
>
> I was also considering the other possibility: using QGraphicsScene and 
QGraphicsItem. That approach would be most similar to the miniTkLeo where 
tree is drawn in Tk.Canvas by adjusting handful of items that can fit 
inside the visible part of tree. Perhaps styling these graphic items would 
be a bit easier than in the NewTreeWidget. When I started I didn't much 
think about styling widget. 

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: Update re: new model

[vitalije]

Rev 35cabb5 

 
fixes top row being different background color. In fact it was not 
different background color but headline edit widget appeared automatically 
on double click (even if double click was not in the headline text). Now it 
is correctly shown only when user actually edits headline.

Font's kind of too big now... I remember a thread from years ago where 
> it seems that Qt doesn't really have a consistent cross platform / 
> cross version way of controlling font size, seeing it interacts with 
> screen DPI etc. 
>
> Cheers -Terry 
>
> Font is now just copied from c.frame.tree.treeWidget, so whatever old tree 
gets from stylesheet about font, the same font is applied to NewTreeWidget. 
Now when running without theme and without myLeoSettings.leo it looks much 
like old Leo. But when theme BreezeDarkTheme.leo is used, on my machine it 
gives smaller font in NewTreeWidget then in old treeWidget, even if they 
use the same font. This is strange, but I don't suppose it is big issue. 
After all it is easy to set larger number in font-size statement in 
stylesheet. 

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: Update re: new model

[Terry Brown]

Outline -> Insert/Delete Icons -> Insert Icon
just places persistent icons with no particularly meaning to any
plugin, even though I was using icons from the todo plugin.

I think you might see the coloring of the "top" node issue if you
experiment with an outline with a really small number of nodes (3-4),
it actually applies to the top N nodes that exist when the outline's
loaded.

Font's kind of too big now... I remember a thread from years ago where
it seems that Qt doesn't really have a consistent cross platform /
cross version way of controlling font size, seeing it interacts with
screen DPI etc.

Cheers -Terry


On Fri, Aug 3, 2018 at 2:31 PM vitalije  wrote:
>
> How do you add those icons? When I click in any icon in the Task pane, it 
> always replaces previous icon with the new one.
>
> I see that icons are smaller than in old tree.
>
> Rev 9d7adae1c now respects setting `@int icon-height` when drawing icons.
>
> 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.

-- 
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: Update re: new model

[vitalije]

How do you add those icons? When I click in any icon in the Task pane, it 
always replaces previous icon with the new one. 

I see that icons are smaller than in old tree.

Rev 9d7adae1c now respects setting `@int icon-height` when drawing icons.

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: Update re: new model

[vitalije]

I don't know how you got this top node in the different background color. 

I have pushed slightly changed version. Icons are now painted over 
background rectangle. Also I have enlarged font size used for tree.

Must say I'm surprised by the "draw the tree yourself" approach, but 
> will see how it pans out. 
>
>
I have tried earlier to use QTreeView and 
QAbstractItemModel/QStandardItemModel and it didn't work. I don't remember 
the details but I think PyQt version of this class wasn't fully supported. 
Some of the key methods were missing. Somehow it was not very suitable for 
the Leo model. OTOH I have several times implemented this drawing so I knew 
it is possible and it works fast. 

In the version you have tried, NewTreeWidget copied font from 
c.frame.tree.treeWidget and I have checked that its pixel size is the same 
as the size in qt style sheet. However, text in NewTreeWidget was smaller. 
So, I changed the code to scale this font 1.5 times to visually match Leo 
normal tree.

Icons are scaled to fit into the height of the row which is approximately 
equal to font height, so increasing font size increases also icons.

Can you test latest version a7ad0ff63

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: Update re: new model

[Terry Brown]

Works better. Attached shows a couple of issues - top node background
is a different color, and adding icons shrinks icons vertically, at
least the first time you add one.

Must say I'm surprised by the "draw the tree yourself" approach, but
will see how it pans out.

Cheers -Terry
On Fri, Aug 3, 2018 at 1:00 PM vitalije  wrote:
>
> @Terry, please try 5ee7b406. When running without theme and without 
> myLeoSettings.leo it couldn't find icons for the NewTreeWidget. Now some 
> defaults are set.
>
> 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.

-- 
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: Update re: new model

[vitalije]

@Terry, please try 5ee7b406 
.
 
When running without theme and without myLeoSettings.leo it couldn't find 
icons for the NewTreeWidget. Now some defaults are set.

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: Update re: new model

[Terry Brown]

Just FYI the tree did not render for me.
Leo 5.7.4 devel, build 20180607085129, Thu Jun  7 08:51:29 CDT 2018
Git repo info: branch = ltm-leo, commit = eb3b09169816
Python 3.6.6, PyQt version 5.6.2
Windows 10 AMD64 (build 10.0.14393) SP0
isPython3: True

probing with g.log(p.h) suggested node creation was working etc.  With HOME
set to /tmp to avoid modified settings, tree was a dark blue rectangle in
regular looking Leo UI

also loading an existing file, even with --no-plugins, crashed.

Cheers -Terry

On Fri, Aug 3, 2018 at 8:08 AM vitalije  wrote:

> Revision eb3b09169
> 
> added support for visual declutter in NewTreeWidget. It also supports
> styling via themes qt style sheet like Leo tree currently does.
>
> All unit tests pass.
>
> I am going to use this code in the next days to see if there are some
> remaining bugs. AFAIK there is only code cleaning and documenting that
> remains to be done. These last fixes introduced quite a lot of new code
> (parsing qt style sheet, de-cluttering nodes...).
>
> This branch is still experimental. Don't use it yet for real work.
>
> Note, anyone who wants to try this branch, the code needs the latest
> version of leoDataModel.py file in leo/core/ folder. This file can be
> obtained from its repository 
> .
>
> 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.
>

-- 
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: Update re: new model

[vitalije]

Revision eb3b09169 

 
added support for visual declutter in NewTreeWidget. It also supports 
styling via themes qt style sheet like Leo tree currently does.

All unit tests pass.

I am going to use this code in the next days to see if there are some 
remaining bugs. AFAIK there is only code cleaning and documenting that 
remains to be done. These last fixes introduced quite a lot of new code 
(parsing qt style sheet, de-cluttering nodes...).

This branch is still experimental. Don't use it yet for real work.

Note, anyone who wants to try this branch, the code needs the latest 
version of leoDataModel.py file in leo/core/ folder. This file can be 
obtained from its repository .

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: Update re: new model

[jkn]

On Wednesday, August 1, 2018 at 3:20:11 PM UTC+1, vitalije wrote:
>
>
>
>> A small point; I suggest not calling the current code 'leo legacy...'. 
>> There is a presumption there that is unwarranted, I think.
>>
>>
> Sorry about that and thanks for the hint. English is not my first 
> language.  What would be correct way to label it "master branch Leo"?
>

Hi Vitalije
I'd suggest just saying 'the current model'.  I don't think that would 
be confusing.

Regards
jon N

-- 
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: Update re: new model

[vitalije]

NewTreeWidget inherits QFrame and draws everything on its own.
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: Update re: new model

[Terry Brown]

re style sheet, I think almost all styling has worked by applying the full
stylesheet once to the top level window widget, from where it's inherited
by all widgets that are descendants of that widget.  I know there's a
performance penalty for applying a large stylesheet frequently, not sure
what it's like for smaller stylesheets, but in general I guess I'm
surprised it doesn't "just work" applying the stylesheet to some high level
container object.

Unless perhaps you're talking about the way styles are mapped from the
stylesheet, e.g. they're currently targeting a QTreeThingy and your code
uses a QTreeWhatsit.  If that's the case it would seem simplest to edit the
stylesheets as needed, to me.

Cheers -Terry


On Wed, Aug 1, 2018 at 9:20 AM vitalije  wrote:

>
>
>> A small point; I suggest not calling the current code 'leo legacy...'.
>> There is a presumption there that is unwarranted, I think.
>>
>>
> Sorry about that and thanks for the hint. English is not my first
> language.  What would be correct way to label it "master branch Leo"?
>
> The latest update: today I started work on making NewTreeWidget aware of
> qt style sheet. So far I have made it respect the theme I am using
> currently (Breeze dark I think). Have to go now, but there are still some
> work to take colors from style sheet.
>
> 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.
>

-- 
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: Update re: new model

[vitalije]

>
> A small point; I suggest not calling the current code 'leo legacy...'. 
> There is a presumption there that is unwarranted, I think.
>
>
Sorry about that and thanks for the hint. English is not my first 
language.  What would be correct way to label it "master branch Leo"?

The latest update: today I started work on making NewTreeWidget aware of qt 
style sheet. So far I have made it respect the theme I am using currently 
(Breeze dark I think). Have to go now, but there are still some work to 
take colors from style sheet.

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: Update re: new model

[jkn]

Hi Vitalije

On Tuesday, July 31, 2018 at 2:50:54 PM UTC+1, vitalije wrote:
>
> Rev 81b1c1422 
> adds
>  
> support for executing old scripts. It has only 7 added lines.
>
> It also turns off auto-scrolling that I used in the beginning when new Leo 
> tree was without its scrollbars. 
>
> Playing with some scripts and comparing speed of different tree 
> traversals. Here is a script:
>
> import timeit
> def t_one():
> res = []
> for p in c.all_positions():
> res.append('%s%s'%(' '*p.level(), p.h))
> return '\n'.join(res)
> def t_two():
> d = c._ltm.data
> res = []
> for lev, gnx in zip(d.levels[1:], d.nodes[1:]):
> nd = d.attrs[gnx]
> res.append('%s%s'%(' '*lev, nd.h))
> return '\n'.join(res)
>
> t1 = timeit.timeit(t_one, number=100)*1000/100
> g.es('leo legacy iterator avg: %.2fms'%t1)
>
> c.USE_NEW_MODEL = True
> t1 = timeit.timeit(t_one, number=100)*1000/100
> g.es('Position2 iterator avg: %.2fms'%t1)
> t1 = timeit.timeit(t_two, number=100)*1000/100
> g.es('Pure new model iterator avg: %.2fms'%t1)
>
>
> and here are the results on my machine with unitTests.leo outline:
> leo legacy iterator avg: 23.76ms
> Position2 iterator avg: 18.75ms
> Pure new model iterator avg: 2.37ms
>
> As you can see using traditional c.all_positions with USE_NEW_MODEL=True 
> is slightly faster then the original one. It uses class Position2 which has 
> the same interface as Position class, but uses data from the new model. But 
> it is possible to compute the same result even faster by using new 
> traversal options. In the above example this approach computes the same 
> result 10 times faster.
>
> Conclusion: the old scripts will work (most of them) as they did before or 
> slightly faster, but with a little bit adjustment they can run even faster. 
> I believe that many user will find worthwhile the effort to change their 
> scripts to be able to use these speed improvements. I would also suggest a 
> setting that will allow users to drop the support of the backward 
> compatibility in exchange for speed.
>
> Vitalije
>

A small point; I suggest not calling the current code 'leo legacy...'. 
There is a presumption there that is unwarranted, I think.

That aside, although I am only tangentially following you work, I find it, 
and your descriptions, very interesting.

Regards
Jon N

-- 
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: Update re: new model

[vitalije]

Rev 879a1227 

 
fixed the issue with chapter selection using combobox in the toolbar.

I have also added few helper methods in new model to make chapterController 
and chapter searching methods more efficient when using new model.

Currently, declutter doesn't work and editing headlines. To edit headline 
one must double click in headline. Using Ctrl+h raises TypeError.
These are next on my todo list.

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: Update re: new model

[vitalije]

Rev 81b1c1422 
adds
 
support for executing old scripts. It has only 7 added lines.

It also turns off auto-scrolling that I used in the beginning when new Leo 
tree was without its scrollbars. 

Playing with some scripts and comparing speed of different tree traversals. 
Here is a script:

import timeit
def t_one():
res = []
for p in c.all_positions():
res.append('%s%s'%(' '*p.level(), p.h))
return '\n'.join(res)
def t_two():
d = c._ltm.data
res = []
for lev, gnx in zip(d.levels[1:], d.nodes[1:]):
nd = d.attrs[gnx]
res.append('%s%s'%(' '*lev, nd.h))
return '\n'.join(res)

t1 = timeit.timeit(t_one, number=100)*1000/100
g.es('leo legacy iterator avg: %.2fms'%t1)

c.USE_NEW_MODEL = True
t1 = timeit.timeit(t_one, number=100)*1000/100
g.es('Position2 iterator avg: %.2fms'%t1)
t1 = timeit.timeit(t_two, number=100)*1000/100
g.es('Pure new model iterator avg: %.2fms'%t1)


and here are the results on my machine with unitTests.leo outline:
leo legacy iterator avg: 23.76ms
Position2 iterator avg: 18.75ms
Pure new model iterator avg: 2.37ms

As you can see using traditional c.all_positions with USE_NEW_MODEL=True is 
slightly faster then the original one. It uses class Position2 which has 
the same interface as Position class, but uses data from the new model. But 
it is possible to compute the same result even faster by using new 
traversal options. In the above example this approach computes the same 
result 10 times faster.

Conclusion: the old scripts will work (most of them) as they did before or 
slightly faster, but with a little bit adjustment they can run even faster. 
I believe that many user will find worthwhile the effort to change their 
scripts to be able to use these speed improvements. I would also suggest a 
setting that will allow users to drop the support of the backward 
compatibility in exchange for speed.

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: Update re: new model

[vitalije]

>
>
> I'm eager to see the code. Could you publish what you have?  I promise not 
> to touch it :-)
>
>> There are also new things I have learned about Leo and I wish to discuss 
>> them but right now I am a bit exhausted and I have to rest for the next few 
>> days.
>>
>
>
I have just pushed current version in ltm-leo branch. In order to work it 
needs file leoDataModel.py inside leo/core/ folder. I haven't added it yet 
to the Leo repository because it is still under development in its own 
repository. To test new code I have created batch file which first copies 
latest version of leoDataModel.py in leo/core/ folder and then launches Leo 
from ltm-leo branch folder.

Current version of leoDataModel.py can be obtained from here 
. 

There are some things I would like to discuss in more detail about Leo's 
design and I am going to start new thread.

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: Update re: new model

[Edward K. Ream]

On Sat, Jul 28, 2018 at 2:40 PM, vitalije  wrote:

I have incorporated new data model into Leo and all unit tests pass.
>

A few more comments.

Two days ago I had a version which passed all tests for the first time.
> However, there have been serious speed issues. Running all tests with new
> model were almost two times slower than running without new model. I was
> utterly disappointed and almost had given up. During the last two days I
> rewrote new position class and commander generators and now everything
> works at least not slower than without new model.
>

I'm glad you didn't give up. Your work is likely to be Leo's future.

...running demote/promote cycle 100 times with creating undo data every
> time didn't cause any GC activity. There has been an increase in memory
> usage (about 300Mb) for these 200 operations on LeoPyRef.leo. If this ever
> becomes a problem, there are some easy ways to encode only the difference
> between current and previous data.
>

I'm not much concerned about GC issues.  In practice, users rarely change
the outline, and almost never make multiple changes at once.

You mentioned earlier that the new data model works like a DB index on the
outline.  This suggests the following:

1. It might be possible to avoid the present problems in deleting
positions, simplifying or eliminating c.deletePositionsInList.

2. It might be possible to represent the new data model using an actual
database.  This might allow Leo to handle outlines containing millions of
nodes.  That's been a dream of mine for a long time.  Such a scheme would
likely moot any GC concerns.

There are still some things that I have to do before publishing code.
>

I'm eager to see the code. Could you publish what you have?  I promise not
to touch it :-)

> There are also new things I have learned about Leo and I wish to discuss
> them but right now I am a bit exhausted and I have to rest for the next few
> days.
>

Please do take as much rest time as you need.  I always do.

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: Update re: new model

[john lunzer]

This *is* exciting. One of my more pressing questions: if a future front 
end were written which does not use PyQt/PySide, would it benefit from the 
same speedups during drawing? 

On Saturday, July 28, 2018 at 3:40:15 PM UTC-4, vitalije wrote:
>
> I have incorporated new data model into Leo and all unit tests pass. I 
> have estimated two weeks would be enough for the task, and today is 
> fifteenth day since I have started (see other thread 
> ). 
> Running all unit tests with new model on my machine takes 40.875s, while 
> running them without new model takes 45.292s. So, after all some speed 
> improvement has been achieved. Certainly this is negligible improvement, 
> but it is important. Let me explain why. 
>
> Two days ago I had a version which passed all tests for the first time. 
> However, there have been serious speed issues. Running all tests with new 
> model were almost two times slower than running without new model. I was 
> utterly disappointed and almost had given up. During the last two days I 
> rewrote new position class and commander generators and now everything 
> works at least not slower than without new model.
>
> Please note, unit-tests are executed using NullGui, so the speed 
> difference between the new tree drawing and old one were not taken into 
> account. And this difference is major speed improvement.
>
> Running experiment like the one shown in the video 
> now takes on average 35ms. 
> The example in video is 1.3ms but it didn't create undo/redo data. Now with 
> creating undo data it takes a bit longer (35ms). It is still 48 times 
> faster than Leo without new data model (which needs 1700ms).
>
> By the way, running demote/promote cycle 100 times with creating undo data 
> every time didn't cause any GC activity. There has been an increase in 
> memory usage (about 300Mb) for these 200 operations on LeoPyRef.leo. If 
> this ever becomes a problem, there are some easy ways to encode only the 
> difference between current and previous data.
>
> There are still some things that I have to do before publishing code. For 
> example, status line is not updated on selection, selecting chapter using 
> minibuffer commands works, but selecting from the select box in the toolbar 
> has no effect. Most likely some plugins that use old tree are not working 
> with the new tree at the moment. I don't expect those issues will take more 
> than a week or two to complete.
>
> Since I have rewritten my initial solution, there are certainly some 
> unused methods and functions all around that I need to clean before 
> publishing code.
>
> There are also new things I have learned about Leo and I wish to discuss 
> them but right now I am a bit exhausted and I have to rest for the next few 
> days.
>
> 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: Update re: new model

[Edward K. Ream]

On Sat, Jul 28, 2018 at 2:40 PM, vitalije  wrote:

> I have incorporated new data model into Leo and all unit tests pass.
>

Thanks for this update.  This is exciting news.  I look forward to studying
what you have done.

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.