Thank you for posting your UI design, Conor. Really nice!
On Wednesday, June 1, 2016 at 4:57:17 AM UTC-7, john lunzer wrote: > > That is pretty rad, thanks for sharing! > > On Wednesday, June 1, 2016 at 7:26:37 AM UTC-4, Conor White-Sullivan wrote: >> >> This is amazing to come across. >> >> I discovered Leo today after scouring the web trying to find some UI >> where people were merging trees to create this a multi-dimensional dag, as >> you describe. Totally in love with what you're doing. >> >> I also had the realization recently that layering trees to form a graph >> could be incredibly powerful >> >> Here's the UI I built this weekend to get started >> >> >> >> <https://lh3.googleusercontent.com/-T_L5LZZPBhM/V06JBKAtnQI/AAAAAAAAAb0/OdRt_KcVOTonmv6KDlL2eki87A6KKwp-QCLcB/s1600/treedom2.gif> >> >> >> Now just have to figure out a Clojure workflow and I'll be using your DAG >> editor to build my graph editor ;) >> >> >> >> On Friday, February 12, 2016 at 4:42:20 AM UTC+5:30, Edward K. Ream wrote: >>> >>> John Lunzer's recent remarks has triggered one of the biggest Aha's in >>> Leo's history, one that was totally unexpected until this afternoon. >>> >>> Leo's fundamental data structure is a tree of nodes. More accurately, >>> it is a Directed Acyclic Graph or dag. Links in such a graph can point >>> "down" the tree, but never up, so there are no cycles. Leo's clones are >>> well defined just exactly because there are no cycles. Given a node, we >>> know precisely *and* intuitively which nodes are descendants. Because >>> of clones, a node may have more than one parent. >>> >>> Here's the Aha. Imagine this data structure as being linked with >>> *black* thread. Now imagine another *completely independent* set of >>> *red* threads. The only requirement is that the links defined by the >>> red threads must *also* be a tree/dag. That is, there is *absolutely no* >>> necessary relationship between the red and black threads. >>> >>> Now imagine that every Leo attribute creates its *own* sets of >>> links/threads. *We have a new view for every attribute.* Let's call >>> such a data structure a *multi-threaded tree/dag*. Trees might actually >>> be enough, but I'm not sure so I'll refer to tree/dag (tree or dag). >>> *Important*: some nodes may not have any thread running them for some >>> colored threads (attributes). That's just fine. >>> >>> Alas, the term "multi-threaded data structure" is commonly used for data >>> structures that can be accessed by independently running threads. That's >>> not at all what I am talking about. >>> >>> I am not aware of anything like this in graph theory. Could this be a >>> truly new idea? I really have no idea. >>> >>> Of course, you could call the resulting structure a general graph, and >>> technically it is, but how the data structure will be used inside Leo is >>> *very >>> *different. Instead of a single, unintuitive mess, we have a collection >>> of easily traversed trees/dags. *We instantly have an arbitrary >>> dimensioned graph*! Each color creates a new dimension. Of course, we >>> only *see* one dimension at a time, but attributes may be the >>> *composition* of other attributes (unions, intersections or other >>> relations), so this is no real restriction. >>> >>> And listen to this. *It is astoundingly easy to create this multi-dag >>> in Leo*. At present, each vnode has a parents list and a children >>> list. All we have to do is replace these two lists by dictionaries whose >>> keys are attributes and whose values are the parents or children lists for >>> those attributes. Finally, we add Python properties shield the dictionary >>> lookup from the rest of Leo. We are talking about maybe 50 lines of code! >>> As far as the rest of Leo is concerned, vnodes *still* have parents and >>> children lists. The switcheroo happens totally invisibly, when the user >>> wants to see another view. The attribute changes and that changes what the >>> vnode dictionary/properties "deliver" to the rest of Leo. >>> >>> To recap: What we see depends only on the attribute that defines the >>> view. This attribute determines what parents and children lists become >>> active. So easy. So very powerful. >>> >>> Each *current view* will show only the nodes with the given attribute. >>> To repeat, attributes can be composed of other attributes, so in effect >>> each view can be associated with an *arbitrary set* of attributes. >>> This is an *astoundingly* general data structure. >>> >>> The real challenge lies in assigning different colored links to nodes. >>> I'm still trying to wrap my thoughts around all of this. >>> >>> As always with truly huge Ahas, it's already impossible to know exactly >>> what thoughts lead to it. As soon as the Aha happened, the world changed >>> so much that the past becomes hard to reconstruct. But for sure the >>> following factors were "in the air": >>> >>> 1. Most importantly, the consensus has been building among the usual >>> suspects that attributes are a more intuitive, and perhaps more powerful, >>> alternative to clones. >>> >>> 2. For the last year I have been trying to ignore the fact that >>> sometimes clones get in the way. This was the meaning of today's remark >>> that "I love clones, I hate clones". >>> >>> 3. John's remark about attributes and hoists certainly triggered the >>> avalanche. >>> >>> *Notice*: multi-threaded tree/dags collapse a lot of behind-the scenes >>> complexity. In particular, both hoists and chapters are a (mildly >>> successful) attempt to make clones do the work of attribute-based views. In >>> the new scheme, we simply re-thread nodes that we want to be part of the >>> new view. >>> >>> *And notice*: when we require that views be made of clones we can *not* >>> change any parent/child relationships. But that constraint completely >>> disappears when we use attributes to define views. >>> >>> *Summary* >>> >>> This is one of the most momentous Aha's in Leo's history. It was >>> completely unexpected this morning. It is almost too easy to make it >>> happen. I may do it this evening. >>> >>> There remain important user interface questions concerning how nodes get >>> assigned various colored threads, but I have faith that the result will be >>> truly amazing. >>> >>> This Aha will have a huge number of happy consequences. Just for >>> starters: >>> >>> 1. Searches can be limited to a single view (thread color). If we don't >>> use clones in a view, each search will find a node at most once. This will >>> erase my biggest pet peeve about Leo! >>> >>> 2. Every view (attribute) can define/create its own set of parent/child >>> relationships, independently of all other views. Afaik, no other data >>> structure is this flexible while still remaining intuitive. >>> >>> 3. It will be *very easy* for attribute editors to show nodes having >>> those attributes in the most natural way *for that attribute* without >>> being constrained in any way by other organizations of the data. Yes, this >>> is really just a restatement of 2, but it's different in practice. >>> >>> No way would this Aha have happened without the interesting >>> conversations that have taken place in the last few months. Well done, all >>> of us! >>> >>> 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 https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
