Nodes arbitrairily contract when inserting near the root node

[Félix]

I thought I was going crazy while trying to debug something weird in leoInteg.... so I tested what I was doing directly in Leo and it turns out it was Leo who was contracting nodes in the outline when I was selecting nodes near the top and using the usual ctrl+i command to insert a node.

Should I grab more data and screen animation captures ? or is this a known bug/feature that I didnt know about?

Thanks to anyone in advance who would care to acknowledge this :) 

--

Félix (edit:typos)

 i'm using : 

Leo Log Window

Leo 6.1-final, master branch, build cfca6f348c

2020-02-09 13:51:19 -0500

Python 3.6.9, PyQt version 5.9.5

linux

read 7 files in 0.03 seconds

read outline in 0.05 seconds

[Félix]

Here is an album of 3 screen captures that show what happens https://imgur.com/a/Zj0IbH7

--

Félix

[vitalije]

On Sunday, May 3, 2020 at 4:59:30 AM UTC+2, Félix wrote:

I thought I was going crazy while trying to debug something weird in leoInteg.... so I tested what I was doing directly in Leo and it turns out it was Leo who was contracting nodes in the outline when I was selecting nodes near the top and using the usual ctrl+i command to insert a node.

This is known Leo's limitation. The expanded node state is using positions to allow expanded state per each separate clone. But positions become invalid when you insert node before them. It means that expanded state becomes invalidated too, therefore most of the states can't survive node insertion (or deletion) near the top.But this affects only clones and their subtrees.

HTH Vitalije

[Félix]

Thank you very much Vitalije for those details... 

Indeed it was in clones as you described!

So thanks again!

--

Félix

On Saturday, May 2, 2020 at 10:59:30 PM UTC-4, Félix wrote:

[Félix]

To Edward, or Vitalije, ... or anyone really :)

(trying to debug yet another behavior in leoInteg, only to find out that Leo does it in the first place, so my code was correct all along!!)

Is this also related to the fact that clones hidden inside folded parents, seem to inherit their (other "twins") clone's collapsed state, from elsewhere in the tree, last expand/collapse state change once they are revealed when unfolding their parent?

--

Félix

[Félix]

More Details: I'm currently testing keeping the (id) identity of nodes with a murmurhash of their 'archived positions' json string representation. Also, in vscode, the collapsed state is preserved by the said 'id'... Thats why i'm looking into clone expand/collapse exact behavior matching.

--

Félix

[Edward K. Ream]

On Thu, Aug 13, 2020 at 12:21 PM Félix <felix...@gmail.com> wrote:

To Edward, or Vitalije, ... or anyone really :)

(trying to debug yet another behavior in leoInteg, only to find out that Leo does it in the first place, so my code was correct all along!!)

My apologies for the confusion. I have made a similar mistake many times in the past. Leo has many settings relating to tree operation:

    leoSettings.leo#@settings-->Tree operation

As a result, it's possible to say only what Leo does by default, not what Leo might actually do.

Edward

P.S. I recently discovered my super power.  Hehe, it's forgetting details, retaining only principles :-) This is quite useful. It's related to pruning of memory during sleep, which is essential for health.  As with all super powers, it has pitfalls.

So perhaps it's not too surprising that I've been willing to put so much effort into a project that hides details until we are ready to see them!

Edward

[Edward K. Ream]

On Thu, Aug 13, 2020 at 12:26 PM Félix <felix...@gmail.com> wrote:

More Details: I'm currently testing keeping the (id) identity of nodes with a murmurhash of their 'archived positions' json string representation. Also, in vscode, the collapsed state is preserved by the said 'id'... Thats why i'm looking into clone expand/collapse exact behavior matching.

Besides the settings I just mentioned, there is some clever code/hack relating to associating positions with vnodes. I don't remember who did what, but I think both Vitalije and I had a hand in the code.

I see that v.__init__ has an expandedPositions ivar. A cff on that should tell you what is going on. I just took a look. I didn't remember any of this, but it seems fairly straightforward. Some parts do explicitly involve clones.

Edward

[Félix]

Thanks for those details and info!

Wanting to refresh the least possible parts of the UI at each user action is what caused me to return into sheding some light on those details...  Exploring further, and trying out more available options in vscode's refresh and rendering has made this issue less problematic. 

Expect a merge into dev, ...and maybe even into master soon :)

--

Félix

[Edward K. Ream]

On Thu, Aug 13, 2020 at 1:50 PM Félix <felix...@gmail.com> wrote:

Expect a merge into dev, ...and maybe even into master soon :)

Aug 13 was my 71st birthday. This is a great present!

Edward

[vitalije]

On Thursday, August 13, 2020 at 7:21:38 PM UTC+2, Félix wrote:

To Edward, or Vitalije, ... or anyone really :)

(trying to debug yet another behavior in leoInteg, only to find out that Leo does it in the first place, so my code was correct all along!!)

I am sorry for being late, but the behavior  that you see is just a consequence of the position instability. When you insert a node in to the tree (or delete one), positions of all following siblings and their subtrees become invalid. Leo decides which nodes should be expanded by keeping track of the expanded positions. When those positions become invalid the information is lost. There is nothing you can do about it at the moment.

I've made some experiments with outline drawing code that use native qt tree item indexes instead of positions but that has not been merged into the devel branch. To be able to use qt tree item indexes instead of positions, Leo have to keep track of all drawn tree items and not to discard them on each redraw, but that is not how Leo draws tree at the moment.

Lately I am too busy working on some other stuff, so I can't work on Leo. Once I get more time, I plan to continue my work on the issue 1598, which might lead to some improvements in the way Leo handles positions/vnodes and drawing.

Vitalije

[Edward K. Ream]

On Sun, Aug 16, 2020 at 11:46 PM vitalije <vita...@gmail.com> wrote:

On Thursday, August 13, 2020 at 7:21:38 PM UTC+2, Félix wrote:

To Edward, or Vitalije, ... or anyone really :)

(trying to debug yet another behavior in leoInteg, only to find out that Leo does it in the first place, so my code was correct all along!!)

I am sorry for being late, but the behavior  that you see is just a consequence of the position instability. When you insert a node in to the tree (or delete one), positions of all following siblings and their subtrees become invalid.

Thanks for checking in. I had forgotten this fact, if I ever knew it explictly.

Edward

[Edward K. Ream]

On Sunday, August 16, 2020 at 11:46:39 PM UTC-5, vitalije wrote:

> ...the behavior  that you see is just a consequence of the position instability. When you insert a node in to the tree (or delete one), positions of all following siblings and their subtrees become invalid. Leo decides which nodes should be expanded by keeping track of the expanded positions. When those positions become invalid the information is lost. There is nothing you can do about it at the moment.

Imo, Leo can and do something about this. I have just created #1631 for this general topic.

Edward

[Edward K. Ream]

On Saturday, May 2, 2020 at 9:59:30 PM UTC-5, Félix wrote:

I thought I was going crazy while trying to debug something weird in leoInteg.... so I tested what I was doing directly in Leo and it turns out it was Leo who was contracting nodes in the outline when I was selecting nodes near the top and using the usual ctrl+i command to insert a node.

Félix, could you provide an example? Everything works as expected in my tests.

Edward