This is an Engineering Notebook post. It will be of interest only to Leo's core devs. Three Ahas appeared yesterday:
- (The big one) Use vnodes instead of npyscreen.TreeData nodes. - Event handling in the curses gui is easy, and almost complete. - Most unit tests should pass when using the null gui. *Using vnodes in the curses gui* After exercise yesterday I saw how to collapse the complexity of the tree code. Aha: use vnodes instead of (a subclass of) npyscreen.TreeData. Instantly, all linkage and update problems go away. This will require an override (rewrite) of npyscreen.MultiLine.update, the code that redraws the outline. That's not a big deal. ML.update does nothing but call curses.addstr, albeit with complicated code to determine the position args to addstr. The override, LeoMLTree.update, will just call c.frame.tree.redraw, that is, CursesTree.redraw.This code is a copy of the code from the Qt gui, with Qt calls commented out. We just need to teach the (ex Qt) drawing code how to use curses. There may be complications. A top-level "*native*" switch in cursesGui2.py will mark the required changes. There should be no need for the npyscreen classes to know anything about this switch: the new code will override all affected npyscreen methods. *Generating events* The curses gui *does* generate events, namely keystrokes and mouse clicks. npyscreen.InputHandler.handle_input is the one and only "event handler". Leo's curses gui code already contains handlers to handle these. These handlers will call several methods in Leo's core, especially, c.frame.tree.select. So you could say that *tree.select is an event handler in Leo's core*. tree.select calls methods in cursesGui2.py. In effect, tree.select generates *other* events. The code (copied from the Qt gui) in cursesGui2.py *already *has lockouts to prevent endless loops. In short, handling events should be easy. *Unit testing with the null gui* The null gui could, and should, represent Leo's tree, body and log panes using *string widgets*, based on the StringTextWrapper in leoFrame.py. In effect, npyscreen widgets are string widgets too. Linking up the string widgets in Leo's null gui would be almost identical to the linking code in CursesGui.createCursesTop & helpers. Once that is done, most unit tests should pass. We could run the unit tests from Leo's bridge, but it would be simpler have the event loop for Leo's --gui=null option do just the following: - load unitTest.leo (using the null gui, of course), - execute run-all-unit-tests-locally, - quit. There is no urgency connected to this Aha, but it's worth noting. *Summary* Using Leo's native tree of vnodes instead of TreeData nodes will eliminate all sorts of problems. LeoMLTree.update will just call c.frame.tree.redraw, that is, CursesTree.redraw. CTree.redraw must generate the proper calls to curses.addstr. The "native" switch in cursesGui.py will mark all the changes. Event handling in the curses gui should much like the Qt gui code. Running unit tests with a null gui (--gui=null) will be very fast. Running tests with --gui=curses is already very fast. 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.
