On Wednesday, May 17, 2017 at 8:58:52 AM UTC-5, Edward K. Ream wrote:
This post describes a collapse in complexity in the LeoMLTree and
> LeoTreeData classes. This post also gives a very fast caching scheme for
> redrawing npyscreen outlines.
>
The caching code is now working, exactly as described. This is the
LeoValues class.
As I write this, I'm not sure *any *caching is required! Perhaps the
desired range of lines can be gotten in a single function call. In the
meantime, LeoValues is simple enough and good enough.
*Notes*
Here are some notes about recent work. They will be useful pre-writing for
the upcoming post to the npyscreen group. As I think about *that* post, I
see that it has a single intention, namely to help people to subclass
npyscreen.MLTree productively. Yes, the post will tell people how to avoid
pitfalls, but complaining about those pitfalls is not part of the plan ;-)
In any case, these notes relate to the pitfalls, and imo #1 might be quite
helpful to others.
1 *Connecting the singleton LeoValues object*: This required several
experiments. Happily, the final code is gratifying simple. First replace
the LeoMLTree.values property with plain ivars:
if native:
_myFullValues = LeoTreeData() # Used only during startup.
values = []
else:
@others
values = property(_getValues, _setValues)
Later, in createCursesTree, set the values ivar:
if native:
leo_tree.values = LeoValues(c=c, tree=leo_tree)
2. *LeoValues.__len__*: As shown above, the LeoValues instance *replaces*
LeoMLTree.values array. The base code asks for len(self.values), so the
following LeoValues method is needed:
def __len__(self):
'''
Return the putative length of the values array,
that is, the number of visible nodes in the outline.
'''
c = self.c
n, p = 0, c.rootPosition()
while p:
n += 1
p.moveToVisNext(c)
return n
This will be called once per full redraw, so its performance doesn't matter.
3. *LeoTreeData getters*: Previously, the dummy tree created a list of
"linked" LeoTreeData nodes, such that the *default* getters in the
npyscreen.TreeData class worked properly. Now (when native is True) the
LeoTreeData objects are simply wrappers for positions, so it will be
necessary to over-ride all the getters. This will be straightforward.
*Summary*
I expect to finish this phase of the project in a day or three. Replacing
the getters will take very little time, but I may experiment with removing
the LeoValues class completely. This would entail a rewrite/revision of
LeoMLTree._redraw.
It may also be possible to eliminate the LeoTreeData class. We shall see.
Otoh, the LeoTreeLine class is almost certainly essential.
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
