On Wed, May 10, 2017 at 12:18 PM, john lunzer <[email protected]> wrote:
> Just tested this in the wild on Windows for the first time. While > minimally functional it's exciting to see this running. The command > "print-bindings" works, but doesn't wrap properly in the log window (which > is fine). I just wanted to check that anything other that "exit-leo" would > work, and it does! > It's also possible to execute run-all-unit-tests-locally from the minibuffer. The results look like they are the same as before. It may go without saying but Python on Windows does not by default come > with curses. Anyone wanting to demo the curses GUI on Windows can go to > http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses to get a curses wheel > for your version of Python. > Yes, that's how I got curses up on Windows. I thought I had documented that, but maybe not. Fantastic work Edward. > Thanks. The pace picked up today. The minibuffer now works in an intuitive manner. I'll retrofit the headline code to match. Please note, everyone, that there is a *lot* of work still to do: - Just now I've been making sure that all classes refer to each other properly. Each of the helpers of createCursesTop now contain "link checks", asserts that all the links are as expected and were not created previously. - Next, all the wrapper classes will be made functional. This will allow Leo's core to update widgets. This should be straightforward and the code should be very fast. - Next, selecting headline widgets must select the proper nodes in the tree, and vice versa. The wrapper tree code will use dicts similar to these dicts in qt_tree.py: self.item2positionDict = {} self.item2vnodeDict = {} self.position2itemDict = {} self.vnode2itemsDict = {} # values are lists of items. self.editWidgetsDict = {} # keys are native edit widgets, values are wrappers. The code *might *be simpler than the Qt code because the curses headline widgets *might* not be recycled when trees are redrawn. Or not. This step can be tricky because the code must be careful to get in an endless "selection loop". The user selects a tree node, which calls the base leoTree.select logic, which selects a tree node, which calls the leoTree.select logic...Happily, npyscreen generates no events on its own. The gui code is free to generate just those "events" (calls to Leo's core) that it needs. It will likely be a week or three before all this is working. Oh yes. One more thing. When the LeoMLTree class is working smoothly, I'd like to refactor it, creating a suggested npyscreen.MLTreeEditable class and a LeoMLTree subclass. My experience suggests that an "Editable" tree class can't be obtained merely by having a class inherit from both MLTree and some other "Editable" class. I'll then propose that MLTreeEditable be part of the npyscreen. 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.
