On Thu, May 13, 2010 at 1:11 PM, Terry Brown <[email protected]> wrote: > On Thu, 13 May 2010 11:37:56 -0500 > "Edward K. Ream" <[email protected]> wrote: > >> Text wrappers allow Leo's core to be gui-independent. > > I think some level of abstraction is a must have. I'd like to see an AJAX > interface for leo, so you can easily make an argument for at least two > interfaces existing simultaneously, even if you wanted to suggest that Tk > will fade away. > > But I wonder about the level at which the abstraction occurs. I think that's > what bugs Ville. If the gui was responsible for telling leo the body text > for node n is now s, rather than telling leo that key k has just been > pressed, things would be simpler.
There are many things in Leo that would be simpler if we discarded essential capabilities. The gui code for the outline is particularly tricky because two kinds of "events" can drive the tree, and therefore changes in nodes: user keys and clicks and commands. User events send information from the tree to the core; commands do the reverse. > But there are so many complications, keybindings for vi emulation, syntax > coloring. I'd like to see head text rendering independent of head text > content, so > > �...@shadow /home/tbrown/Desktop/Projects/AProject/project.py > > could display as > > project.py This would be possible, but it would likely be quite confusing. You would likely need a mode telling whether to show the full path or not. You can get this effect now with @path. > But maybe there could be a different abstraction structure such that leo core > *does* just deal with messages from the gui like "the body text for node n is > now s", so it could either be hooked up to a plain Qt widget or a fancy one > which emulates vi. Then if you wanted to emulate vi in more than one gui, > there might be a vi emulation layer that could sit between leo and different > backend widgets, but it wouldn't be so much in leo's core. Sorry, but Leo's core must understand a lot about widgets, and everything about bindings. Conceivably, leoKeys.py could be refactored to include an abstraction layer. I will be revising leoKeys.py for the vim project, but I doubt anything like what you suggest will look attractive. 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.
