On Wed, Apr 8, 2015 at 11:23 AM, Kent Tenney <[email protected]> wrote:
> > I can see how well they work, however they introduce several new idioms: > - nodes in a body pane instead of the tree pane > - clicking in one part (empty space) of a body pane to put content there > - clicking in another part (button) of a body pane to change focus > - persisting is called 'layout' > - use of the top secret rclick on border > Despite Terry's answers to this, I have similar concerns. In fairness to Terry, is a hard design problem, and potentially a lot of work. Let's do a thought experiment. Suppose the bookmark pane looked and worked like Leo's existing outline pane, except that the nodes were bookmarks. Let's call this the *bookmark outline pane*. *Optionally*, there could be a* bookmark body pane*, containing data associated with each bookmark: notes, explicit UNL's to the target node, whatever. *How useful would this be*? There would be many advantages. The appropriate key bindings would be in effect, so one could navigate, expand and collapse, organize, create and destroy nodes as usual. Creating a node would, presumably, create a bookmark. You get the idea. Navigating the *bookmark * outline pane would *select *the corresponding node in the main outline, which would update the main body pane. If the bookmark outline pane also contained a bookmark body pane, this pane too would automatically update. *Important*: when navigating the bookmark pane, focus would stay in the bookmark pane even though the nodes in the outline pane are also being selected. This is pretty much the way present bookmarks plugin works. In particular, selecting a node in the outline shows that node in context, a very good thing. Despite all the coolness just described, this platinum design has a few drawbacks. 1. This design takes a lot of real estate. I hadn't originally intended to mention it, but the design is looking good enough that it now seems important to point out this drawback explicitly. :-) 2. This design implies constant switching back and forth between the main outline and the bookmark outline. A new toggle-active-outline-pane command would work, but we would be using it a lot. 3. It's easy to blithely talk about how focus will stay in the bookmark panes while also Leo selects nodes in the body pane, but this will be very difficult to do. We are talking about messing with some of the most complex logic in all of Leo. The present bookmarks plugin finesses this problem by never having focus :-) *Summary* This design could work. When I started this reply I didn't realize how good it could be. It would take lots of real estate, and lots of tricky code, but it's not out of the question. Leo's history might have been very different had I started with bookmarks instead of clones. However, there is another question to ask. Is it possible to improve Leo's find commands to eliminate unwanted hits during searches? I'll discuss this in another thread. 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
