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.
