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: Push to Leo Repo Failed with error:Protected branch update failed for refs/heads/devel.

[Matt Wilkie]

hmmm, not sure what's going on here. How about try adding a new file that 
will have no prior history. It can be a blank do nothing thing that we 
remove later.

-- 
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/c0165938-6e0c-4df9-9496-4648bec18dad%40googlegroups.com.

Push to Leo Repo Failed with error:Protected branch update failed for refs/heads/devel.

[Thomas Passin]

Matt, thank you for the setting me up to contribute to the Leo repo.  This 
finally got me past the problem with my password not getting me access.  On 
my first attempt to push viewrendered3, after merging I got this error:

Writing objects: 100% (117/117), 48.58 KiB | 3.04 MiB/s, done.  
Total 117 (delta 89), reused 0 (delta 0)
remote: Resolving deltas: 100% (89/89), completed with 14 local 
objects.
remote: error: GH006: Protected branch update failed for refs/he
ads/devel.  
remote: error: Required status check "continuous-integration/tra
vis-ci" is expected.
To https://github.com/leo-editor/leo-editor.git 
 ! [remote rejected] devel -> devel (protected branch hook d
eclined)
error: failed to push some refs to 'https://github.com/leo-edito
r/leo-editor.git'   
Done 

The viewrendered3 module was not in fact changed in Leo's devel branch.  In 
the future, I suppose I better start a new branch for each change, but I'm 
not sure what to do in this case.

I hope you know what to do about this.  

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/b2a1d682-93bf-4a2f-b12f-c4af0860376f%40googlegroups.com.

Removing Template VMs from Qubes OS!

[Viktor Ransmayr]

Hello Matt & Leo Community,

Am Do., 7. Mai 2020 um 02:14 Uhr schrieb Matt Wilkie :

> looks like posted to wrong mailing list Viktor :)
>

@Matt Wilkie  : Thanks for making me aware of my mistake.

@Leo's Community : Now that I've made that 'mistake', I'd like to use it as
an opportunity to ask any one of you interested in a reasonably secure
development & operating environment to read the available information from
the Qubes OS Project. - See

* https://www.qubes-os.org/

I am learning a lot!

With kind regards,
Viktor

-- 
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/CAAeSrGKv-xxH0gF9FW8hdK%3D6P61%2BJm0J1qkBS%2BJAsskuZvZyqQ%40mail.gmail.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: Problems with abbreviations with non-english keyboards

[Mike Hodson]

The usual way seems to be a shifted comma and period. I suggest looking at
https://en.m.wikipedia.org/wiki/German_keyboard_layout

You're just able to get the key symbols as the OS hands them out, and I
presume someone with a German keyboard will utilize it the way they have
for years, making the symbols the way their keyboard appears in front of
them.

To me this seems to me to be a somewhat mooted point?

Mike


On Wed, May 6, 2020, 16:20 Edward K. Ream  wrote:

> I am finally getting around to #1563
> . To do this I
> started a test file with --trace=keys.  This clearly shows what is
> happening. The problem is what to do next.
>
> In Windows 10 I switched to the German keyboard and typed `alp;;` on my
> keyboard. I got alpöö In other words, the double semicolons turned into öö.
>
> The ö characters are being delivered to Leo's lowest level key code. There
> is nothing that any of Leo's follow-on can do.
>
> It's not clear how users of a German keyboard can type semicolons.
> Presumably there is a way, but I don't know what it is.
>
> I googled "Windows 10 keyboard settings" but didn't come up with anything
> interesting.  Does anyone have any ideas?
>
> 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/57c6f89a-e08d-4622-a94a-e85ff91d928b%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAN%2B%2B4hHZykxNTK5W%3D3Fm5hYbe4_CR14hKwzU4Rvd1n1V1xT58Q%40mail.gmail.com.

Re: [qubes-users] Removing Template VMs?

[Matt Wilkie]

looks like posted to wrong mailing list Viktor :)

-- 
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/a2e70e23-8306-432f-a5ee-e5403a90c3bc%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.

Problems with abbreviations with non-english keyboards

[Edward K. Ream]

I am finally getting around to #1563 
. To do this I 
started a test file with --trace=keys.  This clearly shows what is 
happening. The problem is what to do next.

In Windows 10 I switched to the German keyboard and typed `alp;;` on my 
keyboard. I got alpöö In other words, the double semicolons turned into öö.

The ö characters are being delivered to Leo's lowest level key code. There 
is nothing that any of Leo's follow-on can do.

It's not clear how users of a German keyboard can type semicolons. 
Presumably there is a way, but I don't know what it is.

I googled "Windows 10 keyboard settings" but didn't come up with anything 
interesting.  Does anyone have any ideas?

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/57c6f89a-e08d-4622-a94a-e85ff91d928b%40googlegroups.com.

Fwd: [qubes-users] Removing Template VMs?

[viktor . ransmayr]

Am Dienstag, 5. Mai 2020 20:39:52 UTC+2 schrieb viktor@gmail.com:

> Am Montag, 4. Mai 2020 22:25:13 UTC+2 schrieb dhorf-hfr...@hashmail.org:
>>
>> On Mon, May 04, 2020 at 12:28:27PM -0700, viktor@gmail.com wrote: 
>> > If I'd like to remove any old & **unused** Template VMs (e.g. Debian 9, 
>> > Fedora 29, etc.) all I have to do is to start the Qubes Manager, select 
>> the 
>> > template I'd like to remove - and - select 'Delete qube' ... 
>>
>> this should not work for templates that were installed by rpm. 
>> you will have to use "rpm -e qubes-template-fedora-23" (or similar). 
>
>
> I'm a new user of Qubes OS. - I started to use it only with R4.0.
>
> *Does any of the above concern me?*
>
> this will also require you clean up anything depending on these 
>> templates first, like switching all VMs using them to something else, 
>> removing related dvm templates ... 
>>
>
> I'm aware/ took care of that/ already. - This is why I referred to 'remove 
> old &  unused *** Template VMs'.
>
> i recommend to keep your one-generation-outdated mainline-template 
>> around (even if it is EOL) if you can spare the diskspace. 
>> if you manage to wreck your new mainline template some way, it is 
>> easier to recover from that with an outdated than with no template. 
>>
>
>  This advice of yours I don't fully understand - but - I'll defer it to 
> another message.
>

I could spare the disk space - but - why should I do that?

My understanding from reading the documentation is, that I could re-create 
the deleted Template VM later in time anyhow, should the need arise ...

For example - "sudo qubes-dom0-update qubes-template-fedora-29" - should 
I've had deleted it before.

Thanks in advance for any answers & insights!

With kind regards,

VR

-- 
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/35fbe84c-bcd9-4766-affc-4f1e67fd6b82%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: Thoughts about the mvc prototype

[Edward K. Ream]

On Wed, May 6, 2020 at 6:50 AM vitalije  wrote:

>> I am willing to work on tests if you are willing to share the
programming.
> Of course I am.

Thanks. First, it's time to fix #1563.


> I would like to at least have the ability to run it using an existing
> outline. It might be best if the filename is provided on the command line
> to open that filename and without arguments to create a new outline with
> the single node.
>

That's what rev bce8dc123 does, which I have just pushed.

 I am working on testing using hypothesis
> . I plan to open
> LeoPyRef.db, then hypothesis will randomly select items and perform random
> commands checking after each command that the resulting list of vnodes
> collected in the outline order by iterating v-nodes is exactly the same as
> the one collected by iterating tree items. Hypothesis is good at finding
> short sequence of operations that lead to error. If it doesn't find that
> sequence we may be pretty sure that code is correct.
>

Let me know how it works out.

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/CAMF8tS1r9_xCNpmZRG0qVUhMDrNVE_JYSEcjpZ6vUx%3DtER_ztw%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: Thoughts about the mvc prototype

[vitalije]

>
> I am willing to work on tests if you are willing to share the programming.
>

Of course I am.

 

> Creating full coverage unit tests might be easier if running the prototype 
> without any arguments created an empty outline. The necessary changes are 
> straightforward. I can push the changes I've made locally if you like.
>
>
  Feel free to do anything you want to the prototype. But I would like to 
at least have the ability to run it using an existing outline. It might be 
best if the filename is provided on the command line to open that filename 
and without arguments to create a new outline with the single node.
 
I am working on testing using hypothesis 
. I plan to open LeoPyRef.db, 
then hypothesis will randomly select items and perform random commands 
checking after each command that the resulting list of vnodes collected in 
the outline order by iterating v-nodes is exactly the same as the one 
collected by iterating tree items. Hypothesis is good at finding short 
sequence of operations that lead to error. If it doesn't find that sequence 
we may be pretty sure that code is correct.

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/da0312df-0df1-4b7d-ab9b-94d65e97386e%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: Thoughts about the mvc prototype

[Edward K. Ream]

On Tue, May 5, 2020 at 12:25 PM vitalije  wrote:

I am glad you like it. The issue with cloning top levels is fixed in
> 1edad92fe9b8cd. It was caused by iter_all_v_items which didn't yield
> anything when v is c.hiddenRootNode. Now it checks for this condition and
> yields only rootItem.
>

Everything works for me now.

The QtPosition class is not used yet in the prototype. I started to write
> it to see if it is feasible to make something to hold all traversal methods
> of p and generators. It is not finished yet (the generators are missing).
>

Heh. I didn't realize that.

The QtPosition class is extremely clever. Implementing Position methods
using Qt tree items rather than vnodes promises to break the Gordian Know
of interactions between the gui code and Leo's core.

I think that the next step should be to make some tests for prototype to
> eliminate all crashes.
>

I would suggest creating unit tests that cover all the code. The test code
in leoAst.py might be a template for such a project. I am willing to work
on tests if you are willing to share the programming.

> Manually I test it by running a serious of commands to create a complex
> trees with a lot of clones, inserting new nodes, demoting, moving
> right/left, especially right to get into the cloned node, or moving left
> from cloned node, ... then I undo each step, then redo all steps again,
> then I make series of undo/redo.
>

Creating full coverage unit tests might be easier if running the prototype
without any arguments created an empty outline. The necessary changes are
straightforward. I can push the changes I've made locally if you like.

I thought I had eliminated crashes. Do you remember the steps that lead to
> crash?
>

No, I don't. I'll let you know if the prototype crashes again.

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/CAMF8tS3Z%3DUehCY3zR_VzbbRLC27H9kaZUjewo4UTmWkTv6RTAw%40mail.gmail.com.