Excellent progress yesterday. The following are notes to myself.  Feel
free to ignore them as you like.

The api-for-redraw branch now contains most of what is needed:

1. Unlike the previous go-round, only a few "optimized" methods are
needed, and they are simple:

- redraw_after_head_changed.  This is a do-nothing for qt.  It is (or
will be) a full redraw for Tk.

- redraw_after_icons_changed.  This will update the icon for the
presently selected node, or all visible nodes, depending on an
argument.

- redraw_after_select.  This selects a (tree) node if it is visible
(all ancestors expanded).

Actually, at present, redraw_after_select simply calls the tree.select
in the base class in Leo's core, which in turn calls beforeSelectHint
and afterSelectHint.  Surprisingly, this "just works".  It works
because afterSelectHint forces a full redraw (of all visible nodes,
that is) if there is no item for the selected position.

I think it would be clearer, and smoother, simply to do the full
redraw in redraw_after_select if the current position isn't visible,
but that might not be so easy.  Anyway, we are close to a full
solution that redraws the screen only as needed.

The take-away message is that only three "optimized" redrawing methods
are needed to eliminate all unnecessary redrawing.

2. I see no great need to insert nodes when expanding a node:
redrawing the screen in that case will be good enough.  Trying to be
clever when expanding a node has almost no payoff: the screen *must*
change. A tiny minimization of the change accomplishes almost nothing.

3. I remember why it was useful to delay redrawing in the Tk world.
The problem was flash created by setting focus in multiple places.

The "solution" was to delay the actual setting of focus until the last
possible moment.  This had complexifying effects throughout the code.
Iirc, the major culprit was Pmw.

I've never seen this problem with Qt.  It is a huge help to have Qt
properly buffer screen changes.

4. It turned out to be remarkably easy to force drawing to happen
immediately.  I migrated calls to c.selectPosition into the first
argument of c.redraw.  Both c.redraw and c.redraw_now now cause an
immediate redraw.

5. All unit tests pass in the api-for-redraw branch when using Qt.  I
haven't run those tests when Tk is enabled.  I don't expect major
problems because the "optimized" redraw methods for Tk will simply be
full redraws.  There are places, however, where the distinction
between c.redraw and c.redraw_now is significant for Tk, so real
testing is needed.  Happily, this distinction, which causes so much
pain with Tk, does not matter in Qt.

The to-do list:

1. Test with Tk.  This must be done now to find Tk-specific problems.

2. The clever-redraw branch improved several utility methods, such as
the dictionary getters and the rememberItem method.  This code must be
merged with the api-for-redraw branch.

3. Remove the use_partial_redraw switch.  It's mostly gone now that
the clever-redraw code has been retired.

4. Complete redraw_after_icons_changed, and call it from the core.

5. Remove the (now unused) definitions for the old optimizer methods
from Leo's core.  This is easy: they are all in the same node.

It should only take a few hours of work to complete this list.

Conclusion

The new code already does almost everything that could be desired,
with far less complexity than the doomed clever-redraw code.  There is
no doubt in my mind that the "sweet spot" has been found, both in the
design and in the code.

More testing is needed to verify that all special cases are handled
properly.  This will likely be a bigger issue for the Tk code than the
Qt code.

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
-~----------~----~----~----~------~----~------~--~---

Reply via email to