The clever-redraw branch has to be abandoned because it made too many
changes to Leo's core. But those changes started a cascade of
thoughts that occupied me most of yesterday.
It seems to me that it is time to attempt yet another simplification
of how Leo's core causes redrawing to happen. This must happen in a
new branch, say redraw-api.
This should not be a huge project. I'll be running all unit tests as
I go along, and it should quickly become clear whether the plan makes
sense. If the branch does succeed, it will become the foundation for
future work on the qt gui redraw code.
Background
At present, c.redraw only *schedules* a redraw--actual redrawing
happens in c.outerUpdate. c.redraw_now calls c.redraw and then
immediately calls c.outerUpdate.
A global invariant is that all paths through Leo's code must
eventually call c.outerUpdate. c.doCommand calls c.outerUpdate, and
any event handler that might cause a redraw must also call
c.outerUpdate.
I don't recall why I thought delaying redrawing is ever a good idea.
It seems that the code that requests a redraw is in full possession of
the data needed to do the redraw. Why delay the inevitable?
The proximate cause for this project, however, is something completely
different. The clever-redraw branch contains code such as:
c.setCurrentPosition() # Step 1: set c._currentPosition.
c.redraw_after_insert() # Step 2: create new tree items.
c.selectPosition() # Step 3: select the new tree item.
It now seems clear that redrawing should be a *unified* operation.
That is c.frame.tree.redraw (called from c.redraw) should be
responsible for doing all of the following as a single, *indivisible*
operation:
1. Updating the tree.
2. Selecting the proper node (thus updating the body pane).
3. Selecting the proper tree node.
Indeed, recent work with the "clever" qt gui code shows that there can
be significant interactions between these three operations. In the
past, I have futzed with the order of calls to c.setCurrentPosition,
c.redraw_after_insert and c.selectPosition **in Leo's core**. But
that is tricky and error prone. It would seem much simple and robust
to handle all the complications in one place, namely
c.frame.tree.redraw.
I know from experience that such changes can yield surprises. This
plan has some risk, but almost any amount of work will be worthwhile
if the plan succeeds.
Notes
The way to unify the three operations will be to add arguments to
c.redraw:
- A mandatory argument will specify the node to be selected.
- One or more optional keyword arguments will specify what pane is to
have focus, including whether, if focus is in the tree pane, the
selected node should be open for editing.
I said above that I don't remember why I thought delaying
c.outerUpdate was a good idea. Maybe I'll find out ;-) But if it
turns out that c.outerUpdate isn't needed, it will be a major
simplification to eliminate it. It may be that the fairly recent
elimination of c.beginUpdate and c.endUpdate has cleared the way for
this new simplification. We shall see.
The new branch isn't so much a refactoring of the code as a re-
visioning of how redrawing happens. There is a big difference: the
former is driven by code; the latter is driven by design.
Edward
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en
-~----------~----~----~----~------~----~------~--~---
