On Wed, Oct 1, 2008 at 3:05 PM, Edward K. Ream <[EMAIL PROTECTED]> wrote:
> Hmm. My *guess*, and you might call it more like a hunch, is that the > only place that this could be done are in the low-level *position* > methods: Great - having an "only place" is always good. > @thin leoNodes.py-->class position-->p.Moving, Inserting, Deleting, > Cloning, Sorting > @thin leoNodes.py-->class position-->p.moveToX > @thin leoNodes.py-->class position-->p.Low level methods > > I know this seems very strange. Let me give you some background. It doesn't seem strange at all. Now, if we add code that emits signals whenever a vnode is created, deleted or moved (to child number N of vnode v), we can pretty much hack qleolite to modify the tree in real time, as instructed by the engine (leoBridge). Note that I still think using leoBridge is the best way to reach a state where we have a prototype *you can use* as quickly as possible (i.e. without having to support everything from get-go). After that, we can focus on stuff like turning keyboard events to leo commands, adding a minibuffer, ... (or perhaps the minibuffer should be one of the first things to add, for testing purposes) -- Ville M. Vainio http://tinyurl.com/vainio --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
