On Wed, Dec 25, 2013 at 12:12 PM, Fidel N <[email protected]> wrote:
> Hi: > Related to discussions in recent posts, I would like to go on with the > discussion about what bookmarks can be. > > Whenever we work in Leo, we are doing two things: > > - Search for nodes to edit > - Edit those nodes > > But in order to edit the nodes, we need to relate them to more nodes, so > we create a view of a group of nodes, so we work with them together, then > edit the objective node. > > The key aspects an ideal "view" would have, would be, at least: > - Possibility to store a view, and go back to it later in time. We should > be able to recover that view as unaltered as possible. > - Ease of navigation among views. Hierarchical structure is the ideal way > to store and navigate them. > This is exactly my picture of the relation between nodes/clones and views/bookmarks. Someone talked about storing Bookmarks inside a dictionary. And I agree. > But Edward said its a very nice structure to be hidden, I also agree. Then > we have another problem, we are considering making a new GUI to navigate > this new hierarchical structure. > Not in my picture of the situation. The "Gui" is Leo's outline, exactly as before. The "expansion" of a view node is a (real outline) node whose children are clones of all the nodes described in the view node. Why don't we solve all those 3 problems, and use the current Leo Tree GUI > to navigate > > bookmarks, which would be in a new tree pane, created just for bookmarks > and views? > Imo, what I have just described will suffice. It would work like this: - Select the @bookmark-view node, say @bookmark-view my view - Execute the bookmark-view-unpack command. This command will create a node called "my view" at the end of the outline and populate it with clones of all nodes described (by bookmarks or unl's) in the @bookmark-view node. Alternatively, the @bookmark-view node (wherever it is) could be the root of the created tree, and the clones would be created as its children. Similarly, something like @auto-view <filename> could describe the structure to be "added" to the node @auto <filename>. So *nothing* needs to be added to Leo's gui. Just two or three new commands will suffice. That's why I am so excited: these command can be added in a few hours. Days at most. Whenever we drop a node from our outline into that new Tree pane, it will > display a node, but will actually contain the link to the original node. > Also, this way we could rename them to match our view, meaning: > > We have a node which is the source of the problem. We can drop that node > to our Tree Pane view, just as a child of our current view-node. Then, > since its body is the UNL (and it can contain any other useful references, > like the gnx, creation time of the node, name, etc, so in case of UNL > broken, it could guess out of the rest of information), we can just change > the name of the new node-link we created in our tree outline to "Problem > node". > > For instance: > > > <https://lh5.googleusercontent.com/-RZzqczThQnY/Urse0w2iijI/AAAAAAAAEfw/TnPT4UQl4UM/s1600/2013-12-25+19_00_17.png> > This way, we could drop nodes as we work on our Tree Pane, which would be > instantly linked in our bookmarks view. When we click in a bookmark view > (or control click), the tree pane jumps to its position. They can be named > differently, since the info to the link could be stored in their body, > hidden. > > The new bookmarks pane wouldnt allow any information to be stored in the > body, just the name and their bodies would contain the links. They could > store different Leo files links, making it possible to have a view > containing different Leo files, allowing us to work seamlesly with all our > outlines. > > The left, our information. The right, the way we estabilish relationships > among it. Many ideas come from the speed we will have editing our data. > For instance, nodes with certain type (specific headers, images, etc) > could be auto-filtered into special views. I think this would have many > possibilities. > > What do you think?? > As explained above, Leo can already do what is required, without adding anything except support for @bookmark-view (@view for short). This support consists of new pack/unpack commands. The support for @auto-view can consist of automatic adjustment of the imported @auto tree or, perhaps less confusingly, a single command that will apply the extra formatting explicitly. 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/groups/opt_out.
