Thanks for your reaction, very much agree about all nodes have at least one attribute. Really just trying to work through it and hoping to further incite Edward's brain to help with any clarification, hopefully pointing out where I'd gone wrong in my buildup.
On Friday, February 12, 2016 at 2:14:39 PM UTC-5, Jacob Peck wrote: > > Probably overstepping here, but my input is mixed in below: > > On 2/12/2016 1:38 PM, john lunzer wrote: > > Well, I'm certainly happy to have been part of the conversation. > > On Thursday, February 11, 2016 at 6:12:20 PM UTC-5, Edward K. Ream wrote: > > I see these three statements as fundamental to the data structure: > > *Important*: some nodes may not have any thread running them for some >> colored threads (attributes). That's just fine. > > > >> The only requirement is that the links defined by the red threads must >> *also* be a tree/dag. > > > >> 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. > > > I'm trying to really understand this. > > The way it works now is there is an "underlying" directed acyclic graph > structure *viewed as a tree*. That part is important. We could say that > right now we only have access to a single view I'll call the "classic" > view, with no way to modify the view. Classic referring to the "old" Leo > where every node could have only one attribute. An unacknowledged unnamed > attribute, but there nonetheless. Clones don't create views or use > attributes at all, a clone is merely a node with more than one parent. > Because we're using a tree to view the graph the only way to view a node > with more than one parent is to show that node twice on the tree. This > creates a sort of "pseudo-view" because clones result in showing redundant > information in the same tree. It is the same tree because there is always > an invisible root node which all other nodes descend from. > > Now I'm struggling to understand this new data structure based on your > statements. To start, any viewing of the data structure must be done > through "views". Let's simplify things and say that the fundamental element > in this structure is a node and a single node could have a headline, a > body, and a list of attributes. Lets say a node cannot have children. To > keep things simple things lets start with a situation where you have five > nodes without a defined body/headline/attributes. If these nodes have no > attributes there is no way to view and in effect it appears to the user > that they do no exist because he/she can not access them. So I believe your > first statement is wrong, every node needs at least one attribute. > > I might be stepping on Edward's toes here, but I don't think nodes with > *no* attributes would be viable in his vision. I think every node would at > least need to be connected to the 'master' view. At least, that's the only > sane thing I can come up with. And if the user only ever uses the 'master' > view for storage, and never interacts with it outside of that, then we'd > never have completely invisible nodes. > > Keeping with this simplest case the next step is to add an attribute to > each. We could add a different attribute to each which would provide five > views. Or we could add the same single attribute to each which would create > one view. In this latter case of a single attribute what the user would see > is a flat list of five nodes. Because our fundamental element is a node and > we haven't defined a way to associate nodes with each other other than with > an attribute a flat list is the best we can get. Not very interesting yet. > > I think the interesting part is how we get from a flat list of nodes to > something resembling structure. Perhaps once we add an attribute to these > five nodes, and we switch to that view, any restructuring we do inside that > view is restricted to that view only. Then it just becomes a matter of > using the usual organizational commands/keyboard shortcuts/API calls. Easy > peasy :) > > > To make this a little more interesting let us expand the fundamental > element to have a simple tree structure (for now let's leave clones out of > this, every node in the tree can have only one parent). Without attributes > again there is no view. In the simplest case the root of each tree could be > given an attribute and children would inherit that attribute. If all trees > had the same attribute we're starting to get close to what Leo is right > now. > > Where do threads fit into this? Attributes by themselves do not imply > membership to a thread. Attributes do not imply any parent-child > relationship. Attributes only collect trees into a list to be viewed. And > in fact at this point this is almost exactly what I described in the > previous forum thread as "hoisting a collection of nodes". In that case > nodes as trees. For simplicity a possible restriction there could be the > same as above, marking a node with an attribute would pull in the whole > sub-tree and subsequent nodes couldn't be marked with the same attribute, > this would prevent a sort of "pseudo-clone" being viewed in a hoisted list > of trees. > > In fact from this build up it appears that attributes have nothing to do > with threads. Threads have to include parent-child relationship between > nodes. And based on your description below it seems to disregard any > structure underlying trees of nodes. > > The only requirement is that the links defined by the red threads must >> *also* be a tree/dag. >> > > To be honest, I think the decoupling here is key. There should probably > be convenience commands to copy tree structure from one view/attribute to > another, but that's an implementation detail -- the flexibility allowed by > not imposing these restrictions trumps, in my opinion, any inconveniences. > > Well that's as far as my brain will take me today. Starting to really lose > my grip on the concept. Don't doubt it at all just looking for some more > detailed clarifications. > > Me too! Excited to see where this goes. > > -->Jake > -- 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.
