On Mon, Dec 15, 2008 at 9:12 AM, Terry Brown <[email protected]> wrote:
> The approach your suggesting was basically how my Tk version worked > > http://leo.zwiki.org/GraphEd > > but note the @link node in the screen shot, which had a target node > embedded in the headline (cropped in the screen shot I think). It > sounds like Edward's suggesting that could be avoided now, and that > would be very good. The recent Aha's clear away some objections to putting general graphs in .leo files, but this would be a major and risky project. I vaguely remember thinking that clones can't be defined in a general graph, and then changing my mind about that. In any event, this kind of project has low priority for me. There is a good chance I will never get around to it. That being so, I encourage anyone interested in graphs to find a way to do the following: A. Describe the graph in a Leo node or tree. B. Draw the graph somewhere, that is, in body pane or a special-purpose tab in the log pane. In other words, we basically want to do graph stuff without any changes to "legacy" Leo. > The more seamless the handling of nodes which > occur in both cyclic graphs and the tree the better. Imo, this sounds good, but might not be. Leo's data model, based on DAG's, is it's major strength. The Great Graph Aha says that outlines don't have to be graphs in order to represent graphs. Indeed, graphs are both more complex and less useful (for Leo's purposes) than DAG's. Clearly, it would be cool to embed graphs into Leo trees, but as I have sketched above there seems to be no great need to change Leo's nodes and iterators. > It seems to me that all that's required for the tree code to handle > cyclic graphs is a rule that *only* direct manual expansion of a node > by the user will expand a node that already occurs in its own > "ancestors" list. Any changes to Leo's data model would have far-reaching consequences. Graph-drawing code might work as you describe, but at least the following would also be affected: 1. Some reasonable concept of top-level nodes must be defined. We want the top-level nodes to "cover" the outline, that is, all nodes in a graph must be reachable from a top-level nodes. In general, there are many possible coverings of an arbitrary graph. Do we want users to specify their desired top-level nodes? If so, how. 2. Iterators become more complex, less useful and less intuitive in general graphs. This has the potential to be hugely confusing, as well as difficult or impossible to implement. > Of course that would apply to search functions etc. This is just one special case of the unwelcome complexities introduced by graph iterators. > as well, so it probably would require a core change in leo, Not probably, certainly. In short, nobody should ever assume that the Graph World is ever going to happen. Imo, it would be much better to do A and B above. That way you can do useful work without having to solve truly difficult problems. The GraphEd plugin is a good start. 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 -~----------~----~----~----~------~----~------~--~---
