Re: operating on groups of nodes...
On Thu, 26 Jun 2008 14:42:30 -0700 (PDT) TL <[EMAIL PROTECTED]> wrote: > > What limitations would you put on the node's that could be > simultaneously selected? None... which is already the case with nodes that can be simultaneously marked, of course. > Would they all have to have a common parent > node? If not, what would Leo do with a paste of nodes from different > parents? Well, Paste's probably no big deal because it would just be a matter of making a copy of each of the selected nodes at the target point. Of course clones will find a way of making that more complicated, that's their job :-) But Move would be trickier of course, given the rules about not being your own ancestor. So I guess the polite way would be to attempt to move all the nodes selected to the target position, and if it fails, abort and do nothing. Rather than try and work out if a move is valid before hand it might be easier to save an undo point (should do that anyway), then just back up to it if something goes wrong. Seem reasonable? Cheers -Terry --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: operating on groups of nodes...
What limitations would you put on the node's that could be simultaneously selected? Would they all have to have a common parent node? If not, what would Leo do with a paste of nodes from different parents? TL --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: operating on groups of nodes...
On Thu, 26 Jun 2008 11:37:32 -0500 "Edward K. Ream" <[EMAIL PROTECTED]> wrote: > The simplest thing that could possibly work is to mark nodes > (possibly in a way distinct from standard marks) and then support > commands to operate on such marked nodes. Say commands such as: > clone-marked-nodes, copy-marked-nodes and move-marked nodes. These > would require no changes at all to Leo's tree widget. Of course, the mark mechanism does parallel the idea of multiple selected nodes. Even covers the issue of different representation for the last node selected, that would be the current position, which has an graphical appearance orthogonal to marking. But to be as quick and easy as I'd expect a modern gui to be for marking multiple nodes some kind of Ctrl-click and Shift-click action would be needed. It seems knowing the state of Shift and Ctrl on the click callbacks would require poking into the Tk event currently? I.e. there's no Leo API for that info.? But Tk specificness might be ok, as I suspect other GUI tree widgets (at least the pre-packaged ones) have Ctrl and Shift multi-node selectiong behaviors. Cheers -Terry --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: operating on groups of nodes...
On Thu, Jun 26, 2008 at 11:30 AM, Terry Brown <[EMAIL PROTECTED]> wrote: > > To be as versatile a tool as possible it seems to me that Leo needs to > be able to select and operate on groups of nodes. I've seen the > groupOperations.py plugin, and it's ok, but I don't really think it > addresses the issue. My "add as first/last child button" plugin > (quickMove.py) is another example of an insufficient solution to this > need. > > I think it will be improve Leo uptake if there are simple ways to > select and copy/move/delete multiple nodes, as many people will expect > a tree gui element to permit this. The simplest thing that could possibly work is to mark nodes (possibly in a way distinct from standard marks) and then support commands to operate on such marked nodes. Say commands such as: clone-marked-nodes, copy-marked-nodes and move-marked nodes. These would require no changes at all to Leo's tree widget. Edward P.S. Leo's find tab has checkboxes labeled 'Mark Finds' and 'Mark Changes', which are intended to make marking groups of nodes easier. EKR --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
operating on groups of nodes...
To be as versatile a tool as possible it seems to me that Leo needs to be able to select and operate on groups of nodes. I've seen the groupOperations.py plugin, and it's ok, but I don't really think it addresses the issue. My "add as first/last child button" plugin (quickMove.py) is another example of an insufficient solution to this need. I think it will be improve Leo uptake if there are simple ways to select and copy/move/delete multiple nodes, as many people will expect a tree gui element to permit this. It's perhaps not very important for code editing Leo apps., but for other hierarchy management apps. it is. Leo core wise I'd hope it can be done without too much impact, just add additional methods which returns lists or iterators of selected nodes in addition to the single node position class. I think compatibility issues would be minimized if 'p' and c.currentPosition() just return the last node selected, regardless of there being other nodes selected. If possible indicate the last node selected graphically, you see this in some apps when multiple objects are selected, a different shade of grey for the selection indicator or something. But it would be a lot of works because the vanilla Leo cut/copy/drag etc. would have to be updated to work with it, and tree widgets would need to support it. I'll take my answer off the air :-) Cheers -Terry --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: undo appears to be broken
On Thu, Jun 26, 2008 at 10:06 AM, TL <[EMAIL PROTECTED]> wrote: > > > In summary, it appears that any changes to a node's headline are not > placed in the edit history used by the undo command until after > another node has been selected. Thanks for this report. I'll put it on the list for b2. Edward --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: drag / scroll bug
On Jun 25, 11:54 am, "Edward K. Ream" <[EMAIL PROTECTED]> wrote: > This is a nasty one. The problem is in tkTree.yoffsetTree. The comparison > p1 == p2 fails because the childIndex entries in p1.stack are different from > p2.stack. As a result, the moved node isn't found and a way-too-big offset > is returned. The fix is now on the trunk, rev 590. All unit tests pass, which is significant because the fix was to p.adjustPositionBeforeUnlink, one of Leo's lowest-level node methods. I'll delay b1 for at least a few more days so we can test the trunk thoroughly. Edward --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: undo appears to be broken
Running the latest trunk with the Vim key bindings shows the following
behavior:
Note: all steps below should leave current node in the Command state
(light blue background)
1. Select a node
2. Delete a character ('x' key)
! Undo menu item dimmed
3. Go to next node ('Ctrl-J' key)
! Undo menu item active
4. Delete a character ('x' key)
5. undo delete ('u' key)
! Restores previous node's character
In summary, it appears that any changes to a node's headline are not
placed in the edit history used by the undo command until after
another node has been selected.
TL
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: undo appears to be broken
Running the latest trunk with no user key bindings (myLeoSettings.leo file not used) shows the following behavior: If, while editing a node (node in "Insert" state), an undo operation is attempted, the undo will ignore any changes since the Insert state was entered and, instead, undo the last change that occurred before the Insert state was entered. TL --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
