I thought I was going to sleep, but breakthroughs kept me awake. So here
they are:
*Selecting nodes*
Contrary to what I said in progress report 4, we obviously must be able to
translate between real positions and ap's (archived positions). That's
because clicking on a node in the browser must call a new action, say
app.select_position(ap). Doh! This is necessary so that Leo's core can
track the outline properly.
*Representing Archived Positions*
*Aha*: ap's should just be dicts. Leo's positions have _childIndex, v and
stack ivars, where stack entries are tuples of the form (v, childIndex).
So the *ap dicts* will have the form:
{
'childIndex': p._childIndex,
'v': p.v.gnx,
'stack': [(v.gnx, childIndex) for (v, childIndex) in stack],
}
*Notice*: we use v.gnx instead of the actual vnodes, which are not
serializable. To do this we will need yet another data dict, say
vnode_to_gnx.
Converting between ap dicts and real positions will be straightforward.
*Speed considerations*
At present, LeoApp.init creates data structures for the entire tree. This
takes about 0.17 sec on my machine. This is not an issue at startup, but
it would be a serious problem on full redraws.
*Aha*: We need to make entries for only visible nodes! Indeed, Leo's core
does not use these data at all, and the LeoTree class in leoflexx.py only
needs the data for visible nodes. More details below.
*Remaining work*
In progress report 4 I said that only the following need to be done.
1. Send LeoKeyEvent objects to Leo's core.
2. Redraw the screen when requested to do so.
The next two section will show how easy these are...
*Handling key events*
The JS side will pass a representation of the keystroke to a new action,
app.send_key. This will create a LeoKeyEvent, encapsulated in a dummy
event. app.send_key will then call c.k.masterKeyHandler(event).
c.k.masterKeyHandler does *everything* else. Leo's core will handle the
key stroke and call for redraws as needed. Which brings us to...
*Redrawing the screen quickly*
Earlier I showed how to represent ap's as dicts. A similar trick collapses
the complexity of full redraws and will make redraws as fast as possible.
Requests for redraws will come to a new LeoGui class, which will be on the
Python side (it will by a flx.PyComponent). When the redraw is requested, *the
python side code will know which nodes are expanded*. gui.redraw will call
app.redraw (also on the python side), which will create a serializable *redraw
list*.
The redraw list will be a recursive list of lists, representing all visible
nodes. Entries will have the form (ap, gnx, headline) just as before.
After app.redraw creates this list, it will call a new action, tree.redraw,
which will clear all the tree widgets and then repopulate the tree. Both
app.redraw and tree.redraw should be straightforward.
*Important*: while creating the redraw list, app.redraw will also *recreate*
all the data dicts, but *only* for visible nodes. This will be done in a
single (recursive) pass, just as with Qt's redraw code. *No full traversal
of the outline is needed*. We can expect that app.redraw will take
milliseconds (at most) to create the redraw list and recreate all the data
dicts.
In practice, few nodes will be visible, so both app.redraw and tree.redraw
will be very fast.
*Summary*
In progress report 3 I said, "Don't take this [to-do] list too literally.
It's all...mush in my mind."
The mush is gone. Perhaps only a few days work remain.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
