Re: ENB: rethinking Model/View/Controller split in Leo

[David Szent-Györgyi]

Edward writes: 

The great advantage Qt has (or had) over Tk was in the appearance of text. 
> Has Tk improved in that regard?
>

My guess is that tkinter as shipped with Python 3.6.8 and 3.7.7 and 3.8.2 
would need careful testing. The macOS interface via Tcl/Tk is undergoing 
work - at present, the ball is in the court of the developers of Tcl/Tk. 

See IDLE and tkinter with Tcl/Tk on macOS, which documents that python.org 
Python installers for versions 3.8.0+, 3.7.2+, 3.6.8 all ship with built-in 
Tcl/Tk 8.6.8. 

See Python bug tracker issue 35402 , 
which documents reverting the use of Tcl/Tk 8.6.9.1, and Python bug tracker 
issue 35485 , which documents specific 
problems and gives a reference to the Tcl/Tk ticket 
 that documents the 
problem.  The current release of Tcl/Tk is 8.6.10; that dates from November 
of 2019, and it hasn't been tried with Python as yet, but I see on the 
timeline for Tcl/Tk  that work 
on the macOS interface is under way as I type this in May of 2020, so the 
bundled Tcl/Tk 8.6.8 won't be upgraded immediately. The developers are 
working around macOS bugs, and Apple is changing the operating system 
significantly, so their work is not easy. 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/4dc190f4-6790-4085-8432-88ac87ee59a6%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Thomas Passin]

On Thursday, May 7, 2020 at 11:49:31 AM UTC-4, tfer wrote:
>
> Thanks Matt and Thomas, I'll look into that.  It's not that I want to 
> avoid Zoom so much, I want to demonstrate some work flow stuff, (Windows 
> 10, some Powershell stuff, and It's virtual workspace), so that's why I 
> need to show what's on my screen.
> If anyone is interested, and it's okay with Edward more people could jump 
> on the call .
>

 I have a periodic Zoom meeting for my particular software project.  One of 
the people acts as the recorder/secretary.  He gets the screen control and 
pulls up the (Word) document that records progress and issues, scrolls 
through it, and we see him update it while we discuss the issues.  The only 
thing is that it's a bit slow compared with being at your own screen.  At 
the end of the meeting, his work is done and he emails us the revised doc.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/4d4c5537-2557-4792-8284-5fab135911ac%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[David Szent-Györgyi]

Edward writes: 

>
> Thanks for this update. Vitalije recently created a prototype in Tk, so 
> there is actually some code available.
>
> The great advantage Qt has (or had) over Tk was in the appearance of text. 
> Has Tk improved in that regard?
>

Answer for Windows: work has been done. See the Python bug tracker issue 
26698 , which states that a fix for 
IDLE on Windows made it into Python 3.6.6rc1 and Python 3.7.0rc1. That work 
was superseded by work documented by Python bug tracker issue 33656 
. 

Issue 33656 mentions the addition of a call to a Windows API to say that tk 
scales for DPI - the change is in Iines 15-20 of the source code 

. 

That change is documented in as new in Python 3.6.6 
 and new in Python 3.7 
. In each case, the text 
reads, 

On Windows, a new API call tells Windows that tk scales for DPI. On Windows 
> 8.1+ or 10, with DPI compatibility properties of the Python binary 
> unchanged, and a monitor resolution greater than 96 DPI, this should make 
> text and lines sharper. It should otherwise have no effect. (Contributed by 
> Terry Jan Reedy in bpo-33656 .) 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/dc51bb77-c4f1-47c3-b607-2a2bc5735b62%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

['tfer' via leo-editor]

Thanks Matt and Thomas, I'll look into that.  It's not that I want to avoid 
Zoom so much, I want to demonstrate some work flow stuff, (Windows 10, some 
Powershell stuff, and It's virtual workspace), so that's why I need to show 
what's on my screen.
If anyone is interested, and it's okay with Edward more people could jump on 
the call .
 
>>> A 'live' reference to an object that will change in real-time...
  -- I like that a lot, I'll probably add it in my rework of the documentation, 
thanks Felix

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/d9867f12-ef72-4487-8b9b-e4f507f220ab%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Félix]

The "Clone" terminology used in Leo is also used in some 2d and 3d 
graphical design software among others, in the same manner: A 'live' 
reference to an object that will change in real-time... 

Just thought I'd make this fact known to people reading this thread :)

On Wednesday, May 6, 2020 at 6:20:59 PM UTC-4, tfer wrote:
>
> >>> I've never had a problem with the term as used in Leo.  To me, it 
> conveys 1) that a (clone) node looks different from another because it 
> appears in a different place, but 2) if you look closer, it's exactly the 
> same inside. 
>
> I'm not saying that the term that the term should be abandoned, just that 
> it should have the points that you see, mentioned more explicitly in the 
> documentation.  Personally, my understanding of cloning from biology lead 
> me astray.
>
> "Clone" is as term of art, it's just that it's meaning in Leo is more 
> specialized than it is in general usage.
>
> I've had trouble in the past trying to get my point across to Edward, I 
> suspect that in part, this is due to different thinking styles, I tend to 
> see thinks visually, coming up with a mental model, and elaborating on that 
> so it has all the behavior of the system I'm modeling.
>
> Leo sucks me in every time I come back for a visit, (it's a pleasant side 
> trip each time), currently, I've been pulled towards a review of the 
> documentation. Going round and round with Sphinx trying to get a PDF 
> rendering as I find that easiest to review.
>
> In a week or so, I'd like to do some teleconferencing with Edward, (not 
> Zoom, but something with the ability to share computer screens), so I can 
> do a show and tell on some of the stuff in Leo I'm working on.
> Tom
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/237e8f7d-f9b2-4138-9809-e4ebffdf41ad%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Matt Wilkie]

>
> In a week or so, I'd like to do some teleconferencing with Edward, (not 
>> Zoom, but something with the ability to share computer screens), so I can 
>> do a show and tell on some of the stuff in Leo I'm working on.
>>
>> Actually, Zoom does let you share your screen.  The host can let any 
> participant take control, and they can share their screen.
>

If it's Zoom in particular you're looking to avoid Jitsi is worth 
investigating:
https://meet.jit.si/

-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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/b2545d10-c688-4379-a874-6a815ec6148b%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Thomas Passin]

Actually, Zoom does let you share your screen.  The host can let any 
participant take control, and they can share their screen.

On Wednesday, May 6, 2020 at 6:20:59 PM UTC-4, tfer wrote:
>
>
> In a week or so, I'd like to do some teleconferencing with Edward, (not 
> Zoom, but something with the ability to share computer screens), so I can 
> do a show and tell on some of the stuff in Leo I'm working on.
> Tom
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/171fdab3-f344-4542-8a0b-fb91ed8d365d%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Matt Wilkie]

> >>> I've never had a problem with the term as used in Leo.  To me, it 
> conveys 1) that a (clone) node looks different from another because it 
> appears in a different place, but 2) if you look closer, it's exactly the 
> same inside. 
>
> I'm not saying that the term that the term should be abandoned, just that 
> it should have the points that you see, mentioned more explicitly in the 
> documentation.  Personally, my understanding of cloning from biology lead 
> me astray.
>

For me I found your contrast of clone as it's used in biology and as it's 
used in Leo useful. The term portal, not as generally communicative to the 
world as is clone in my opinion, is helpful in this conversation. I've not 
thought of a better word or short phrase than clone though. I definitely 
like the visuals of portals and corridors. After today I might foreverafter 
hear the Star Trek transporter sound effect when using "goto any clone" 
command. ;-)

-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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/a57b8711-c07c-414c-be98-a9add0229b28%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

['tfer' via leo-editor]

>>> I've never had a problem with the term as used in Leo.  To me, it conveys 
>>> 1) that a (clone) node looks different from another because it appears in a 
>>> different place, but 2) if you look closer, it's exactly the same inside. 

I'm not saying that the term that the term should be abandoned, just that it 
should have the points that you see, mentioned more explicitly in the 
documentation.  Personally, my understanding of cloning from biology lead me 
astray.

"Clone" is as term of art, it's just that it's meaning in Leo is more 
specialized than it is in general usage.

I've had trouble in the past trying to get my point across to Edward, I suspect 
that in part, this is due to different thinking styles, I tend to see thinks 
visually, coming up with a mental model, and elaborating on that so it has all 
the behavior of the system I'm modeling.

Leo sucks me in every time I come back for a visit, (it's a pleasant side trip 
each time), currently, I've been pulled towards a review of the documentation. 
Going round and round with Sphinx trying to get a PDF rendering as I find that 
easiest to review.

In a week or so, I'd like to do some teleconferencing with Edward, (not Zoom, 
but something with the ability to share computer screens), so I can do a show 
and tell on some of the stuff in Leo I'm working on.
Tom

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0ad2cdcd-a9a2-490c-a625-1977b52dc935%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Edward K. Ream]

On Wed, May 6, 2020 at 1:26 PM David Szent-Györgyi  wrote:

> Tkinter and enhancements for current Python are far more capable than the
plain Tkinter in which Edward wrote the GUI that was part of Leo 4.2 and
Leo 4.3.

Thanks for this update. Vitalije recently created a prototype in Tk, so
there is actually some code available.

The great advantage Qt has (or had) over Tk was in the appearance of text.
Has Tk improved in that regard?

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS2Z_ppDU5SKrvkac0s%2B5jYAFZYoabbpmscfppzEW6B7Xg%40mail.gmail.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[David Szent-Györgyi]

On Monday, May 4, 2020 at 8:23:17 AM UTC-4, Edward K. Ream wrote:
>
> Leo does not support a tk gui.  It hasn't for at least a decade. See 
> leoPlugins.leo#Plugins-->Gui.
>
> It's possible to run tk code from Leo, but that is another matter entirely.
>

The Leo distributions had a virtue that is not shared by the current code: 
simplicity of installation and use. I could fit the installers for Python, 
for pywin32, and the LEO files for my projects on a CD-RW or a thumb drive, 
and be ready in two minutes to work on the outlines in which I was 
developing code. The Tkinter interface of the time was not pretty, but it 
worked, and allowed me to get my work done. I miss that simplicity! 

Tkinter and enhancements for current Python are far more capable than the 
plain Tkinter in which Edward wrote the GUI that was part of Leo 4.2 and 
Leo 4.3. I wonder whether a from-scratch implementation of a Leo GUI using 
modern Tkinter could be done without the pain caused to Edward by the gaps 
in the old toolkit:

Tkinter.ttk 
 is 
themeable, to help Python-Tkinter GUIs match the appearance of native GUIs. 

The BWidget  widgets include a tree 
widget. 

I'm not assuming that Edward or another of you reading this would do the 
work. I *am *curious, because I could really use Leo as a PIM in the 
environments in which I work: macOS 10.13 "High Sierra" or later, 64-bit 
Windows 10 with IronPython already installed, and 64-bit Windows 10 with 
Python 3.7 installed. My macOS environment is stable although it changes 
every couple of years to track Apple's upgrade treadmill, the others switch 
machines frequently. So, for me, ease of installation is a need. 

I'm not asking for an explanation here of the best practices for installing 
current Leo with the Qt-based interface. If the answer to my curiosity 
about making a Tkinter GUI anew is that it simply isn't practical, I'll 
discuss my view of using current Leo and Qt in a separate thread. 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0eb4f36d-281d-40cb-ae76-373c523586f2%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Thomas Passin]

On Wednesday, May 6, 2020 at 1:26:08 PM UTC-4, Edward K. Ream wrote:
>
> On Wed, May 6, 2020 at 9:37 AM 'tfer' via leo-editor <
> leo-e...@googlegroups.com > wrote:
>
> I've expressed before that I feel that the use of the word "clone", does 
>> not really capture what we are doing here, in fact, due to its use in 
>> biology
>>
>
> Hmm. In the Leo world the term "clone" is a term of art 
> . I see no 
> inherent reason why this should confuse people.
>
> Edward
>

I've never had a problem with the term as used in Leo.  To me, it conveys 
1) that a (clone) node looks different from another because it appears in a 
different place, but 2) if you look closer, it's exactly the same inside. 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/405c0d4c-d631-46dc-ac2a-466b2d93a362%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Edward K. Ream]

On Wed, May 6, 2020 at 9:37 AM 'tfer' via leo-editor <
leo-editor@googlegroups.com> wrote:

I've expressed before that I feel that the use of the word "clone", does
> not really capture what we are doing here, in fact, due to its use in
> biology
>

Hmm. In the Leo world the term "clone" is a term of art
. I see no
inherent reason why this should confuse people.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS03Q9agoj7k%2BPacFgNz2Pdh2d6jriTE7iD5HazrXR%3D2Qg%40mail.gmail.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Edward K. Ream]

On Wednesday, May 6, 2020 at 8:21:59 AM UTC-5, Edward K. Ream wrote:

>> I would still recommend that p.clone and other methods for model 
modifications get redirected to tree.clone_node, tree.move_node_up...

> I have a queasy feeling about this. It would seem to imply major changes 
to the console gui code.

Just to be clear, the prototype is so good that I seen no risk at all in 
exploring it. Good things are sure to come from it.

Furthermore, since you (Vitalije) and I have somewhat different points of 
view, the final result will likely be better than either of us imagines at 
present.

Finally, when the dust settles, I am willing to consider changes to both 
the console and flexx guis if that seems warranted.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/74010797-00a2-4710-a975-730250cf84b4%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

['tfer' via leo-editor]

I've expressed before that I feel that the use of the word "clone", does 
not really capture what we are doing here, in fact, due to its use in 
biology, it leads to some incorrect thinking about what is going on.  In 
biology, a clone is a separate entity with its own life-cycle, they have 
the same DNA, but can have entirely different lives.  In Leo, a clone is 
the same entity, what you do to it in one place, (or to its descendants), 
gets passed on to the clones in all the other places, not because of some 
code running in the background updating all the copies, there are no 
copies, there is only one node, but it is reachable from multiple places.

In the talk on Leo I gave at PyOhio, (to which there is a link Leo  
documentation), I tried to convey this by making an analogy to the computer 
game "Portal", if you have some room you want to get to, you can create 
multiple ways to get to it with your portal gun. There is only one room, 
but now you have made several different ways to get to it.

In a recent thread, Edward said that a clone is a node with multiple 
parents.  That was revelatory to me, I'm still thinking over the 
implications of that.  To me it shifts what "being a clone" means from the 
node to the path to the node.  Visually, it means that when walking down 
the corridor to our node, there are now side corridors that join into it 
from anywhere we want in own outline.  

On Monday, May 4, 2020 at 12:23:08 AM UTC-4, Thomas Passin wrote:
>
> I'm always in favor of good separation of interests.  It can be hard to 
> achieve in practice, and it's always helpful to be diligent about keeping 
> one's eye on the ball.  What I'm reading here sounds pretty interesting.
>
> About clones, we always talk about cloning nodes, but it seems to me that 
> what actually gets cloned is an entire subtree - that is, the clone 
> includes (clones of) a node's descendants.  Perhaps a change in the 
> conceptual model of clones from nodes to subtrees would make it easier to 
> work out how to handle them.
>
> I'm not sure how a subtree is currently modeled in Leo.  Since a tree can 
> be built out of nodes that have child and parent nodes,  one can be 
> constructed without an explicit model for a (sub)tree.  But since many 
> operations we want to do are really on (sub)trees and not nodes, maybe an 
> explicit tree concept in addition to a node concept would be useful(if 
> there isn't one already).
>
> On Sunday, May 3, 2020 at 6:12:04 PM UTC-4, SegundoBob wrote:
>>
>> I've been thinking about implementing a directed graph editor for a long 
>> time.  Of course, most of my thinking is based on my use of Leo-Editor and 
>> my limited understanding of its internals.  I've done only a little 
>> implementation of my ideas.  I have not produced anything of use to me or 
>> of interest to anyone else.
>>
>> But several months ago, I concluded that Leo-Editor positions are a very 
>> bad idea and that using  GNX's instead would be much simpler and much more 
>> robust.  I also concluded that in a directed graph, I don't need clones 
>> because multiple parents is no big deal in a directed graph.  Consequently, 
>> I stopped worrying about clones.  So I don't know if clones make GNX's 
>> inadequate as pointers, requiring that v-nodes be used as pointers instead 
>> of just GNX's.
>>
>> For the little it is worth, in so far as I understand Vitalije, and I 
>> don't completely understand him, I think he is right.
>>
>> Respectfully,
>> SegundoBob
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/9d69b6f1-179c-48aa-9f24-1979ed5a8b02%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Edward K. Ream]

On Wed, May 6, 2020 at 7:32 AM vitalije  wrote:

> The tree-refresh branch is not finished and some operations like this one
doesn't work. But the essence of the applied algorithm is correct.

Alright. I'll take a look at the code without cloning 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS2iESvgm6cwbgoM8FB%3DpGu%3DWV%3DKR%3DMCukwFAeS7VTe%3DTw%40mail.gmail.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Edward K. Ream]

On Wed, May 6, 2020 at 7:17 AM vitalije  wrote:

>> I don't mind if c.redraw becomes a do-nothing. I just want to know how
it's going to work.

For outline modifications initiated by scripts we will have to redraw the
> outline. To make it quick I plan to use diff algorithm similar to one I
> wrote earlier in the tree-refresh branch.
>

Hmm. I suppose that would work. If it's fast enough it could be called
automatically at the end of every command, including execute-script.

I would still recommend that p.clone and other methods for model
> modifications get redirected to tree.clone_node, tree.move_node_up,... and
> others. They will automatically update view. This updates should be quite
> fast and no need to distinguish them from pure model modifications. This
> screen updates can be prevented by using tree.blockSignals if necessary.
>

I have a queasy feeling about this. It would seem to imply major changes to
the console gui code.

Btw, I forgot to mention in my earlier comments that w.blockSignals looks
like the way to avoid lockouts.

> The only way to modify the outline that we can't really control is when
> scripts use only v-nodes for making direct links like
> parent_v.children.append(child) or similar. For those modifications we need
> to redraw the tree after each script execution.
>

Or maybe redraw after idle time.

All modifications from the Leo core, should be just redirected to their
> doubles implemented in tree (c.clone -> tree.clone_node, c.moveOutlineUp ->
> tree.move_node_up, ...)
>

I'd like to withhold judgment about all of this for now.

Imo, the prototype, including the tree-refresh branch, is worth further
exploration. The ideal would be to leave all the assumptions behind Leo's
core unchanged.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS17uDF%3DRRw7c4HChu%2ByAGHJ0Ho37cRoAdbK8qNL21Ai9Q%40mail.gmail.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[vitalije]

>
>
> I checked out tree-refresh, then attempted to clone qt_tree.py:
>
> Traceback (most recent call last):
>
>   File "c:\leo.repo\leo-editor\leo\core\leoCommands.py", line 2282, in 
> executeAnyCommand
> return command(event)
>
>   File "c:\leo.repo\leo-editor\leo\core\leoGlobals.py", line 245, in 
> commander_command_wrapper
> method(event=event)
>
>   File "c:\leo.repo\leo-editor\leo\commands\commanderOutlineCommands.py", 
> line 736, in clone
> c.redraw(clone)
>
>   File "c:\leo.repo\leo-editor\leo\core\leoCommands.py", line 2950, in 
> redraw
> p2 = c.frame.tree.redraw(p)
>
>   File "c:\leo.repo\leo-editor\leo\plugins\qt_tree.py", line 309, in 
> full_redraw
> self.drawTopTree(p)
>
>   File "c:\leo.repo\leo-editor\leo\plugins\qt_tree.py", line 635, in 
> drawTopTree
> apply_deletes(deletes)
>
>   File "c:\leo.repo\leo-editor\leo\plugins\qt_tree.py", line 596, in 
> apply_deletes
> v2i[vch].remove(chitem)
>
> ValueError: list.remove(x): x not in list
>
> Edward
>

The tree-refresh branch is not finished and some operations like this one 
doesn't work. But the essence of the applied algorithm is correct. It 
basically creates a set of all links that exist in the outline. Links are 
represented by tuples (parent_v, child_v, index). The set can be calculated 
very fast and using python set operations difference on the set cached 
during the previous redraw and the current set, gives a set of links that 
need to be deleted and set of links that need to be established. This 
algorithm must be adjusted a bit to work with the prototype but it is 
doable. The undo/redo code in the prototype relies on preserving the tree 
items while the algorithm in its current version drops the items and create 
new ones. Other than that it should work without problems. If undo/redo 
code in the prototype is not required this limitation on preserving the 
tree items can be lifted.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/71efcfe8-687c-45eb-ba6f-83f97001e410%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[vitalije]

On Wednesday, May 6, 2020 at 12:51:50 PM UTC+2, Edward K. Ream wrote:
>
> On Sunday, May 3, 2020 at 4:11:48 PM UTC-5, vitalije wrote:
>
> in this prototype all those outline operations are made at the same time 
>> in both tree widget data-model and in v-nodes. This eliminates need for 
>> synchronization between these two models. No need for c.redraw_after..., 
>> c.redraw, c.redraw_later,... No need for several locks, for checking if the 
>> selected position is visible or not, is it outside hoist/chapter,...
>>
>
> I'm not sure what I think about this plan. How do you propose to handle 
> outline operations initiated from scripts?
>
> In the "real" Leo, scripts can update the outline (both model and view) in 
> one of two ways:
>
> 1. Call methods such as c.clone. These Commands methods call c.redraw 
> "automatically".
>
> 2. Call methods, such as p.clone. These Position methods don't call 
> c.redraw. The script must then c.redraw explicitly.
>
> I don't mind if c.redraw becomes a do-nothing. I just want to know how 
> it's going to work.
>
> Edward
>


For outline modifications initiated by scripts we will have to redraw the 
outline. To make it quick I plan to use diff algorithm similar to one I 
wrote earlier in the tree-refresh branch.

I would still recommend that p.clone and other methods for model 
modifications get redirected to tree.clone_node, tree.move_node_up,... and 
others. They will automatically update view. This updates should be quite 
fast and no need to distinguish them from pure model modifications. This 
screen updates can be prevented by using tree.blockSignlas if necessary.

The only way to modify the outline that we can't really control is when 
scripts use only v-nodes for making direct links like 
parent_v.children.append(child) or similar. For those modifications we need 
to redraw the tree after each script execution.

All modifications from the Leo core, should be just redirected to their 
doubles implemented in tree (c.clone -> tree.clone_node, c.moveOutlineUp -> 
tree.move_node_up, ...)

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/ca69e901-ba1c-45eb-8b2a-0ad6020e038e%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Edward K. Ream]

On Sunday, May 3, 2020 at 4:11:48 PM UTC-5, vitalije wrote:


*What about user scripts that modify outline?*
>
> User scripts should work without any modification. They can freely modify 
> outline using the standard Position class or even directly manipulating 
> v-nodes. This will certainly cause tree widget data model to get out of 
> sync. The possible solution would be to make a snapshot of the current 
> outline shape before executing user script. When the script finishes, Leo 
> will compare outline shape with the last snapshot and apply differences to 
> the tree data-model to re-synchronize it. The code for this 
> re-synchronization can be found in another branch tree-refresh.
>

I checked out tree-refresh, then attempted to clone qt_tree.py:

Traceback (most recent call last):

  File "c:\leo.repo\leo-editor\leo\core\leoCommands.py", line 2282, in 
executeAnyCommand
return command(event)

  File "c:\leo.repo\leo-editor\leo\core\leoGlobals.py", line 245, in 
commander_command_wrapper
method(event=event)

  File "c:\leo.repo\leo-editor\leo\commands\commanderOutlineCommands.py", 
line 736, in clone
c.redraw(clone)

  File "c:\leo.repo\leo-editor\leo\core\leoCommands.py", line 2950, in 
redraw
p2 = c.frame.tree.redraw(p)

  File "c:\leo.repo\leo-editor\leo\plugins\qt_tree.py", line 309, in 
full_redraw
self.drawTopTree(p)

  File "c:\leo.repo\leo-editor\leo\plugins\qt_tree.py", line 635, in 
drawTopTree
apply_deletes(deletes)

  File "c:\leo.repo\leo-editor\leo\plugins\qt_tree.py", line 596, in 
apply_deletes
v2i[vch].remove(chitem)

ValueError: list.remove(x): x not in list

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/be597d93-49de-4666-b6b4-5dcda3d5d9ae%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Edward K. Ream]

On Wednesday, May 6, 2020 at 6:01:31 AM UTC-5, Edward K. Ream wrote:

> Clones are well defined only in a DAG. Similarly, "outline order" is well 
defined only in a DAG.

Perhaps I should say that clones are not *uniquely* or *intuitively *defined 
in general graphs. We could go down a rabbit hole here, but I'd rather not. 
Suffice it to say that in general it's hard to generalize about general 
graphs, directed or otherwise :-)

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/558ab079-151a-4a91-acfe-4849ea32faa7%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Edward K. Ream]

On Sun, May 3, 2020 at 11:23 PM Thomas Passin  wrote:

About clones, we always talk about cloning nodes, but it seems to me that
> what actually gets cloned is an entire subtree
>

Correct.

> I'm not sure how a subtree is currently modeled in Leo.
>

This has a long history.  The result of this history is that the tree
contains nothing but pointers (references) to vnodes. This is the so-called
"unified node" world. In this world, clones are simply additional
references to a vnodes. That is, vnodes may have multiple parent vnodes,
provided that there are no "cycles" (loops) in the resulting graph.

> Since a tree can be built out of nodes that have child and parent nodes,
> one can be constructed without an explicit model for a (sub)tree.  But
> since many operations we want to do are really on (sub)trees and not nodes,
> maybe an explicit tree concept in addition to a node concept would be
> useful(if there isn't one already).
>

It's very unlikely that Leo's vnode structure will ever 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS1jN1PyB3FF77cxFYiZxF25KfMczUoA2s8QcBBSOHQ5YA%40mail.gmail.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Edward K. Ream]

On Sun, May 3, 2020 at 5:12 PM SegundoBob  wrote:

several months ago, I concluded that Leo-Editor positions are a very bad
> idea and that using  GNX's instead would be much simpler and much more
> robust.
>

I think that's an overstatement. Scripts are free to use either vnodes or
positions as they please.

> I also concluded that in a directed graph, I don't need clones because
> multiple parents is no big deal in a directed graph.
>

Clones are well defined only in a DAG. Similarly, "outline order" is well
defined only in a DAG.

It is possible to define various kinds of traversals on general directed
graphs . These are more
complex and less intuitive than for DAGs, but they may be useful in special
situations.


> Consequently, I stopped worrying about clones.  So I don't know if clones
> make GNX's inadequate as pointers, requiring that v-nodes be used as
> pointers instead of just GNX's.
>

Each vnode has a unique, unchanging gnx, so on some level of understanding
you can use gnx's or vnodes interchangeably.

For the little it is worth, in so far as I understand Vitalije, and I don't
> completely understand him, I think he is right.
>

Imo, Vitalije has create a useful and important distinction about
positions. They can be used either to identify vnodes or as the basis of
traversal methods.  I'd like to reserve judgement about the new scheme for
now.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0BCVxj%2BGREPnkV0bQwuXzrhZDUXiNmCGaFdq_tvbH_QA%40mail.gmail.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Edward K. Ream]

On Sunday, May 3, 2020 at 4:11:48 PM UTC-5, vitalije wrote:

in this prototype all those outline operations are made at the same time in 
> both tree widget data-model and in v-nodes. This eliminates need for 
> synchronization between these two models. No need for c.redraw_after..., 
> c.redraw, c.redraw_later,... No need for several locks, for checking if the 
> selected position is visible or not, is it outside hoist/chapter,...
>

I'm not sure what I think about this plan. How do you propose to handle 
outline operations initiated from scripts?

In the "real" Leo, scripts can update the outline (both model and view) in 
one of two ways:

1. Call methods such as c.clone. These Commands methods call c.redraw 
"automatically".

2. Call methods, such as p.clone. These Position methods don't call 
c.redraw. The script must then c.redraw explicitly.

I don't mind if c.redraw becomes a do-nothing. I just want to know how it's 
going to work.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3a32ff64-163a-4874-8acc-241c7b948443%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Félix]

just thought i'd mention i'm glad to see other people concerned about 
separation of leo's core features/model and it's GUI... Been fiddling 
around for alomst a year with leo's API and vsCode's API to use the 'pure' 
leo 'model' into another view and controller: vscode.

So i'm very happy to see this discussion going on! 

So a little update : now working on the last features that are a bit 
problematic to me : undo, redo and execute script. I predict having a new 
master branch release for everyone to try/test by the end of May. (they are 
problematic because of vscode technical details, not leo hehe!)

Y'all have a great Day ! :)
--
Félix

On Sunday, May 3, 2020 at 5:11:48 PM UTC-4, vitalije wrote:
>
> The relevant code is in the mvc-prototype branch in 
> leo/extensions/myleoqt.py.
>
> Leo architecture follows MVC design pattern. However during its long 
> history some code parts ended up misplaced. In this post I'll try to 
> explain why I think that the present split between Model, View and 
> Controller is not optimal.
>
> There were several factors that caused this misplacement. Moving from Tk 
> to Qt (and for a long time keeping both GUIs around) is one of the causes. 
> Tk didn't have tree widget and Leo had to provide tree drawing code. By 
> switching to Qt which has a decent tree widget and keeping the old method 
> for drawing nodes Leo didn't use Qt tree widget to its full potential. Also 
> adding some features like user defined icons per node, chapters and 
> hoist/dehoist commands many of the native tree widget features were not 
> used but instead they were re-implemented. All these features are natively 
> supported by qt tree widget. They naturally belong to the *View* but they 
> ended up in *model* and in *controller*.
>
> In every GUI framework which has a tree widget like Qt, wxPython, 
> Jython/Swing, ... Tree widget has its own data model. The more powerful 
> widget is, the more data goes in its model and more work for Leo to 
> synchronize its own model with the model of tree widget.
>
> By moving these features from Leo's *Controller* and *Model* to the *View* 
> the synchronization between Leo's *Model* and tree widgets model becomes 
> greatly simplified.
>
> To prove this claim I wrote a little prototype. It is a Qt application 
> which has three widgets: tree, body and toolbar. It can read Leo documents 
> in '.leo.db' format. To keep this prototype as simple as possible I didn't 
> want to add reading and writing of external files. The '.leo.db' file 
> contains the whole outline (including external files).
>
> In the toolbar there are several buttons for outline modification 
> commands. Moving selected node up, down, left or right; demoting and 
> promoting selected node, as well as undo/redo buttons. Using these buttons 
> one can freely modify outline and then undo or redo operations. Selecting 
> nodes in the tree causes body to show content of the selected node. One can 
> edit body and changes will be recorded in Leo's model. Node can be selected 
> either by mouse click or using keyboard when tree has focus. By double 
> clicking node user can edit the headline and the change will be recorded in 
> Leo's model too.
>
> [Note that undo/redo work only for outline modifications not for typing in 
> body or changing the headlines.]
>
> There are also hoist and dehoist commands that work just like in Leo. If 
> you hoist on the node whose headline starts with '@chapter' its children 
> will become top level nodes. Otherwise hoisted node becomes the only top 
> level node. Dehoist button returns the tree in its previous state. Hoists 
> can be stacked.
>
> All this functionality is achieved in less than 500 lines including 
> comments.
>
> *How it works?*
>
> Instead of making changes in Leo's model (by linking and unlinking 
> v-nodes) and then asking the tree to re-arrange its items according to the 
> v-nodes which is at least O(n) complexity operation and can be a 
> performance bottleneck for large outlines, or even worse asking the tree to 
> recreate the whole data model from scratch, in this prototype all those 
> outline operations are made at the same time in both tree widget data-model 
> and in v-nodes. This eliminates need for synchronization between these two 
> models. No need for c.redraw_after..., c.redraw, c.redraw_later,... No need 
> for several locks, for checking if the selected position is visible or not, 
> is it outside hoist/chapter,...
>
> Then there is a nice feature that each clone can be expanded or collapsed 
> independently of the other clones. In Leo this feature suffers from 
> instability of position instances when outline changes. In this prototype 
> this feature is fully supported. I haven't implemented yet preserving this 
> expanded/collapsed state between two application runs, but it would be 
> trivial to store this information in the c.db and restore it back on next 
> run.
>
> Please note that in this prototype I haven't use 

Re: ENB: rethinking Model/View/Controller split in Leo

[Edward K. Ream]

On Mon, May 4, 2020 at 9:25 AM jkn  wrote:

My apologies for the noise in that case. I had not realised that tk was no
> longer supported. "at least a decade"? - wow, how time flies...
>

No need for an apology!

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0fovVpB3V2gx8tMZHiwdZpPf1uKkTMFqPNGKEcB_SAYQ%40mail.gmail.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[jkn]

On Monday, May 4, 2020 at 1:23:17 PM UTC+1, Edward K. Ream wrote:
>
> On Monday, May 4, 2020 at 4:37:03 AM UTC-5, jkn wrote:
>
> > As far as I know tk has not been retired, and Leo 'must' continue to 
> support it. Or have I missed some news?
>
> Leo does not support a tk gui.  It hasn't for at least a decade. See 
> leoPlugins.leo#Plugins-->Gui.
>
> It's possible to run tk code from Leo, but that is another matter entirely.
>
> Edward
>

My apologies for the noise in that case. I had not realised that tk was no 
longer supported. "at least a decade"? - wow, how time flies...

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/f91290bc-15e5-424f-ba3e-82e0174d1cdb%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Edward K. Ream]

On Monday, May 4, 2020 at 4:37:03 AM UTC-5, jkn wrote:

> As far as I know tk has not been retired, and Leo 'must' continue to 
support it. Or have I missed some news?

Leo does not support a tk gui.  It hasn't for at least a decade. See 
leoPlugins.leo#Plugins-->Gui.

It's possible to run tk code from Leo, but that is another matter entirely.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/7658feaa-3c95-4afb-86c7-818dea9d3917%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[vitalije]

The latest version of prototype is 84b54fc3af.

Currently it is almost 1000 lines including comments and includes the 
following features:

browsing outline
editing headlines
editing bodies
shows basic Leo icons on nodes
inserting new nodes
deleting nodes
moving nodes up, down, left or right
promote / demote
hoist / de-hoist
cloning nodes
undo/redo for outline editing commands

I don't plan to work more on this prototype. Its purpose is to prove my 
claims from the beginning of this post. I believe this covers about 5000 
lines of code in Leo:
- LeoQTreeWidget ~ 500,
- LeoTree ~ 350,
- leoChapters.py ~ 480,
- qt_tree.py ~ 1430,
- leoUndo.py ~ 1730
- ... total 4490 LOC + about 500 lines for implementing all these 
commands.

This means that the bugs have about 4000 lines more space to hide than is 
necessary.
It is also 4000 lines more for CPU to execute and a lot of those lines are 
inside
loops. By applying all these refactorings Leo's code will be much smaller 
and hopefully
it will run much faster.

The prototype is not fully documented. There are a few not very obvious 
methods that
I had to rewrite several times to eliminate bugs that I haven't spotted at 
first.
Those methods require more detailed explanation.

First is make_undoable_move. Here it is:
def make_undoable_move(self, oldparent, srcindex, newparent, dstindex):
t = self.tree
root = t.invisibleRootItem()
trash = []

newitems = [(x, oldparent.child(srcindex).clone())
for x in all_other_items(root, newparent)]
def domove():
for item in all_other_items(root, oldparent):
trash.append(item.takeChild(srcindex))

for item, child in newitems:
item.insertChild(dstindex, child)

curr = move_treeitem(oldparent, srcindex, newparent, dstindex)

self.tree.setCurrentItem(curr)

def undomove():
for item, child in newitems:
item.takeChild(dstindex)

for item in all_other_items(root, oldparent):
item.insertChild(srcindex, trash.pop())

curr = move_treeitem(newparent, dstindex, oldparent, srcindex)

self.tree.setCurrentItem(curr)

domove()

self.c.addUndo(undomove, domove)


oldparent and newparent are tree widget items, and srcindex/dstindex are 
ints. At first I was creating and deleting child items inside functions 
domove and undomove. However, this caused exceptions when performing undo 
and redo later, because redo would create new items and maybe next undo 
block relies on the items that used to be created before. To solve this 
issue, all necessary items must be created outside domove/undomove and all 
items that will be deleted by this command must be kept in local variable 
trash. This pattern I had to repeat in other commands as well.

Generator all_other_items yields tree widget items that point to the same v 
node, skipping the given one. This generator uses links between v-nodes so 
the order of the execution is important. In this method this order of the 
execution doesn't matter but in some other methods it does.

When moving item from one parent to another one, if the oldparent is cloned 
or belongs to the cloned subtree it means we have to remove child not only 
from the oldparent, but from all other items that point to the same v node 
as oldparent. It means we will have to delete some items. The deleted items 
will go to trash from where we will be able to collect them again during 
the undo command.

OTOH if the newparent is part of cloned subtree, that means we will need 
extra items to insert in every other clone. The command moves single item 
from oldparent to the newparent and all other clones both on the source 
side and on the destination side are processed using all_other_items 
generator. Sometimes like in this method the results of this generator are 
kept in local variable and iterated again using that variable (like 
newitems variable above).

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/f22b17c0-aace-45bc-a8b9-a6f6931134b4%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Edward K. Ream]

On Sun, May 3, 2020 at 4:11 PM vitalije  wrote:

The relevant code is in the mvc-prototype branch in
> leo/extensions/myleoqt.py.
>
> Leo architecture follows MVC design pattern. However during its long
> history some code parts ended up misplaced. In this post I'll try to
> explain why I think that the present split between Model, View and
> Controller is not optimal.
>

Many thanks for this post. I was busy with other matters yesterday, and I
am just now reading this.

I'll say more in the next day or so. For now, you have convinced me that
this post and the prototype code merit serious study.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0%2BL1YZjp-eJnMTNmSqngjo4ns9MZuLW9B7oTX7xxyJ%3Dg%40mail.gmail.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[vitalije]

> interesting stuff - but I want to check.question an assumption here. 
> As far as I know tk has not been retired, and Leo 'must' continue to 
> support it. Or have I missed some news?
>
> Jon N
>
>
AFAIK Tk support has been discontinued. There are some Tk remains  in Leo's 
code base, but I don't think it is possible to run Leo with TkGui anymore. 

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/30bc6db1-4aef-4460-8aa6-9606fc5c47ba%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[jkn]

On Sunday, May 3, 2020 at 10:11:48 PM UTC+1, vitalije wrote:
>
> The relevant code is in the mvc-prototype branch in 
> leo/extensions/myleoqt.py.
>
> Leo architecture follows MVC design pattern. However during its long 
> history some code parts ended up misplaced. In this post I'll try to 
> explain why I think that the present split between Model, View and 
> Controller is not optimal.
>
> There were several factors that caused this misplacement. Moving from Tk 
> to Qt (and for a long time keeping both GUIs around) is one of the causes. 
> Tk didn't have tree widget and Leo had to provide tree drawing code. By 
> switching to Qt which has a decent tree widget and keeping the old method 
> for drawing nodes Leo didn't use Qt tree widget to its full potential. Also 
> adding some features like user defined icons per node, chapters and 
> hoist/dehoist commands many of the native tree widget features were not 
> used but instead they were re-implemented. All these features are natively 
> supported by qt tree widget. They naturally belong to the *View* but they 
> ended up in *model* and in *controller*.
>
> In every GUI framework which has a tree widget like Qt, wxPython, 
> Jython/Swing, ... Tree widget has its own data model. The more powerful 
> widget is, the more data goes in its model and more work for Leo to 
> synchronize its own model with the model of tree widget.
>
> By moving these features from Leo's *Controller* and *Model* to the *View* 
> the synchronization between Leo's *Model* and tree widgets model becomes 
> greatly simplified.
>
> To prove this claim I wrote a little prototype. It is a Qt application 
> which has three widgets: tree, body and toolbar. It can read Leo documents 
> in '.leo.db' format. To keep this prototype as simple as possible I didn't 
> want to add reading and writing of external files. The '.leo.db' file 
> contains the whole outline (including external files).
>
> In the toolbar there are several buttons for outline modification 
> commands. Moving selected node up, down, left or right; demoting and 
> promoting selected node, as well as undo/redo buttons. Using these buttons 
> one can freely modify outline and then undo or redo operations. Selecting 
> nodes in the tree causes body to show content of the selected node. One can 
> edit body and changes will be recorded in Leo's model. Node can be selected 
> either by mouse click or using keyboard when tree has focus. By double 
> clicking node user can edit the headline and the change will be recorded in 
> Leo's model too.
>
> [Note that undo/redo work only for outline modifications not for typing in 
> body or changing the headlines.]
>
> There are also hoist and dehoist commands that work just like in Leo. If 
> you hoist on the node whose headline starts with '@chapter' its children 
> will become top level nodes. Otherwise hoisted node becomes the only top 
> level node. Dehoist button returns the tree in its previous state. Hoists 
> can be stacked.
>
> All this functionality is achieved in less than 500 lines including 
> comments.
>
> *How it works?*
>
> Instead of making changes in Leo's model (by linking and unlinking 
> v-nodes) and then asking the tree to re-arrange its items according to the 
> v-nodes which is at least O(n) complexity operation and can be a 
> performance bottleneck for large outlines, or even worse asking the tree to 
> recreate the whole data model from scratch, in this prototype all those 
> outline operations are made at the same time in both tree widget data-model 
> and in v-nodes. This eliminates need for synchronization between these two 
> models. No need for c.redraw_after..., c.redraw, c.redraw_later,... No need 
> for several locks, for checking if the selected position is visible or not, 
> is it outside hoist/chapter,...
>
> Then there is a nice feature that each clone can be expanded or collapsed 
> independently of the other clones. In Leo this feature suffers from 
> instability of position instances when outline changes. In this prototype 
> this feature is fully supported. I haven't implemented yet preserving this 
> expanded/collapsed state between two application runs, but it would be 
> trivial to store this information in the c.db and restore it back on next 
> run.
>
> Please note that in this prototype I haven't use the leoNodes.Position 
> class at all. In Leo's current code the Positions are used everywhere and 
> their instability makes many of Leo's methods much more complicated than it 
> is really necessary. The way I see it, positions are used in two ways.
>
>1. as a handle for v. (whenever p.v, p.h, p.b, p.u, p.is... are used). 
>And Position was meant to be just a pointer to some v node on its 
>particular place in the outline. Now, every tree widget must have its own 
>data-model and its own way of pointing to the particular node painted on 
>the screen. In Qt it is a trivial to attach user data to those pointers. 
>

Re: ENB: rethinking Model/View/Controller split in Leo

[vitalije]

The new version of the prototype now contains 750 lines and a few more 
commands:

   - insert new node
   - delete node
   - clone node

Also in the first version prototype didn't handle clones correctly. In the 
latest version 69953a0f77 

 
handling clones should be correct. I'll try to write some tests to be sure.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/63c06385-b799-4f57-ae96-a2944e5524a9%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[vitalije]

Thomas Passin, thanks for your comment.

On Monday, May 4, 2020 at 6:23:08 AM UTC+2, Thomas Passin wrote:
>
>
> About clones, we always talk about cloning nodes, but it seems to me that 
> what actually gets cloned is an entire subtree - that is, the clone 
> includes (clones of) a node's descendants.  Perhaps a change in the 
> conceptual model of clones from nodes to subtrees would make it easier to 
> work out how to handle them.
>
> I'm not sure how a subtree is currently modeled in Leo.  Since a tree can 
> be built out of nodes that have child and parent nodes,  one can be 
> constructed without an explicit model for a (sub)tree.  But since many 
> operations we want to do are really on (sub)trees and not nodes, maybe an 
> explicit tree concept in addition to a node concept would be useful(if 
> there isn't one already).
>
>
VNode in Leo is always a subtree, although this subtree may be empty (it 
may contain no other nodes). In its current implementation it is not 
possible to separate node from the subtree. If a node contains at least one 
child, it is no longer possible to make a clone of just that node without 
its children. If you try to remove children from the clone, they will be 
removed from the outline too. You can copy just values from v node if you 
wish to have it isolated from its subtree for example when storing Leo 
document in '.db' format, all v-nodes are decomposed to their values (gnx, 
h, b, u, statusBits) and two lists one for parents and one for the 
children. Those two lists contain only gnxes not real v-nodes. Decomposed 
nodes are then stored in the db table. Later when we want to restore the 
outline from the db table we first create every node as an isolated single 
node not connected to any other node. And after all nodes are created, then 
we go through every list of gnxes and using them we link all children to 
their parents and vice versa. Of course this is not the only way to 
decompose v-nodes and recreate them from the decomposed data.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/8b40d601-403b-4887-a789-7ecc1429de9b%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[vitalije]

SegundoBob, thanks for your comments. Multiple parents in Leo nodes is a 
way to keep track of all places clone can be found in the outline. Without 
this `parents` field, every time we need to find other clones it would be 
necessary to search entire tree. Having parents, it is possible to find 
positions of node without searching entire tree.

On Monday, May 4, 2020 at 12:12:04 AM UTC+2, SegundoBob wrote:
>
>
> For the little it is worth, in so far as I understand Vitalije, and I 
> don't completely understand him, I think he is right.
>
>
Which parts you didn't completely understand. Can you please point at some 
part that I haven't explained clearly enough, so that I can try to write 
better explanation.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/51f1bb48-57fe-40d5-a3ca-1cb41931382d%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Thomas Passin]

I'm always in favor of good separation of interests.  It can be hard to 
achieve in practice, and it's always helpful to be diligent about keeping 
one's eye on the ball.  What I'm reading here sounds pretty interesting.

About clones, we always talk about cloning nodes, but it seems to me that 
what actually gets cloned is an entire subtree - that is, the clone 
includes (clones of) a node's descendants.  Perhaps a change in the 
conceptual model of clones from nodes to subtrees would make it easier to 
work out how to handle them.

I'm not sure how a subtree is currently modeled in Leo.  Since a tree can 
be built out of nodes that have child and parent nodes,  one can be 
constructed without an explicit model for a (sub)tree.  But since many 
operations we want to do are really on (sub)trees and not nodes, maybe an 
explicit tree concept in addition to a node concept would be useful(if 
there isn't one already).

On Sunday, May 3, 2020 at 6:12:04 PM UTC-4, SegundoBob wrote:
>
> I've been thinking about implementing a directed graph editor for a long 
> time.  Of course, most of my thinking is based on my use of Leo-Editor and 
> my limited understanding of its internals.  I've done only a little 
> implementation of my ideas.  I have not produced anything of use to me or 
> of interest to anyone else.
>
> But several months ago, I concluded that Leo-Editor positions are a very 
> bad idea and that using  GNX's instead would be much simpler and much more 
> robust.  I also concluded that in a directed graph, I don't need clones 
> because multiple parents is no big deal in a directed graph.  Consequently, 
> I stopped worrying about clones.  So I don't know if clones make GNX's 
> inadequate as pointers, requiring that v-nodes be used as pointers instead 
> of just GNX's.
>
> For the little it is worth, in so far as I understand Vitalije, and I 
> don't completely understand him, I think he is right.
>
> Respectfully,
> SegundoBob
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/a217cec6-f6b5-40b6-b696-4e366b27810d%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[SegundoBob]

I've been thinking about implementing a directed graph editor for a long 
time.  Of course, most of my thinking is based on my use of Leo-Editor and 
my limited understanding of its internals.  I've done only a little 
implementation of my ideas.  I have not produced anything of use to me or 
of interest to anyone else.

But several months ago, I concluded that Leo-Editor positions are a very 
bad idea and that using  GNX's instead would be much simpler and much more 
robust.  I also concluded that in a directed graph, I don't need clones 
because multiple parents is no big deal in a directed graph.  Consequently, 
I stopped worrying about clones.  So I don't know if clones make GNX's 
inadequate as pointers, requiring that v-nodes be used as pointers instead 
of just GNX's.

For the little it is worth, in so far as I understand Vitalije, and I don't 
completely understand him, I think he is right.

Respectfully,
SegundoBob

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/00f1ac75-6700-49d6-9a90-a551be45de6d%40googlegroups.com.