The curses gui project could fail only if it were too difficult to implement Leo's high-level interface. The Aha described here shows that this won't happen :-)
*Background: The high-level interface* Leo's core uses the high-level interface exclusively to change Leo's screens. As a result Leo's core knows *nothing* abut gui-specific details. This is the separation of concerns that makes it possible to support multiple guis. The methods to be written are in leoPlugins.leo# @file cursesGui2.py--> class CursesTextWrapper(object)-->cw.High-level interface-->curses-specific (To do) The main methods of concern are: getAllText, setAllText, getInsertPoint, getSelectionRange setSelectionRange, and seeInsertPoint. As we shall see, other methods, such as insert and delete, can be implemented (efficiently!) in terms of getAllText and setAllText. *The Aha*Last night I studied TextfieldBase class and its super class, MultiLine, trying to understand how I might implement, say, setAllText and setSelectionRange. It quickly became obvious that each class's update method is where all the action is. These are *very *complicated methods. It would not be pleasant to have to change these. But as soon as I *stopped* studying the code I realize that I don't have to understand (or change) the *algorithms* at all. All Leo needs to know is the *data* the algorithms use. But Aha!, these data are *very *simple. They are just the value of the "values" arg passed into the ctor, which is just a list of strings!! Similarly, the data for the cursor and selection range are just ints! In effect, *these data are npyscreen's low-level screen buffer!* Leo's high-level methods can simply get and set these data directly. *No redrawing is needed.* When all work is done, Leo's redraw method will call npyscreen's Form.update to redraw the entire screen. *Summary* Unlike with Qt, Leo's high-level interface methods for the curses gui can get and set npyscreen's screen buffer directly. This is a *huge* performance advantage. All operations of the high-level interface will be operations on ints, strings or arrays of strings. The curses gui should be at least 10x faster than the Qt gui, *regardless* of the complexity or speed of npyscreen's update methods! Leo's curses gui code will have *no* knowledge of the update algorithms. No patching will be required. Leo should be able to use the latest npyscreen code without changes. Leo's curses code will know only about the very simple data (ints, strings and arrays of strings). npyscreen is unlikely ever to change this data. If it does, the changes to Leo's curses gui will be straightforward. Only Leo's redraw method (part of the high-level interface) will call Form.update. No redraws *at all* will be needed during unit tests of the curses gui! This Aha removes the last tiny bit of anxiety from the curses gui project. It is now clear that the project will succeed. 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.
