Got it (I used backlinks.py instead of backlink.py). Now, just need to decipher how to use it; not initially obvious (nothing in the plugin docstring by way of direction that I can find).
Rob............ On Tuesday, February 16, 2016 at 11:40:30 PM UTC-5, Terry Brown wrote: > > On Tue, 16 Feb 2016 20:32:03 -0800 (PST) > Largo84 <[email protected] <javascript:>> wrote: > > > Maybe a stupid question, but where do I find the plugin? It doesn't > > load from the standard GitHub repo. > > They're in the standard repo. - let me check the names... > > backlink.py > graphcanvas.py > > from my settings @enabled-plugins, superseding any other spellings I > may have offered. > > Not sure about Python 3 compatibility though... > > Cheers -Terry > > > Rob............... > > > > > > On Tuesday, February 16, 2016 at 6:04:54 PM UTC-5, Terry Brown wrote: > > > > > > Hmm, well, at risk of sounding like a broken record, you could use > > > the backlinks plugin, the attached image shows A and B in their > > > "native" or "outline" relationship (or lack thereof) in the tree, > > > then in backlinks (middle pane) with a link via a node > > > "blocking_dependency" which is a rich relationship description with > > > "severity" and "description" components, and in the bottom pane in > > > graphcanvas plugin, which uses backlinks for its relationships > > > (they're two interfaces to the same info.). Sorry about the colors, > > > but the white arrow is the parent->child relationship of Nodes Y > > > and B, and the black arrows run through the "blocking_dependency" > > > relationship node as described. > > > > > > You could use the same approach in place of clones for gathering > > > nodes relevant to a particular bug or something, just link all the > > > nodes of interest to one otherwise unrelated "issue" node, which > > > perhaps resides in a list of such issues. I'd tend to use > > > bookmarks plugin instead, although I'm realizing how much > > > redundancy there is between backlinks and bookmarks... hmm, they're > > > not really the same, phew ;-) > > > > > > I'm not sure how tractable the API is for using backlinks in > > > scripts, there's some support I think, and of course more can be > > > added if there's demand. > > > > > > Cheers -Terry > > > > > > ------------------------------ > > > *From:* Largo84 <[email protected] <javascript:>> > > > *To:* leo-editor <[email protected] <javascript:>> > > > *Cc:* [email protected] <javascript:> > > > *Sent:* Tuesday, February 16, 2016 3:36 PM > > > *Subject:* Re: Attributes vs. Relationships > > > > > > Yes, Terry, that's a good description of what I envision. Is that > > > possible now? If so, I don't see the mechanism. How (where) would > > > you create that link? > > > > > > Rob............. > > > > > > On Tuesday, February 16, 2016 at 4:25:13 PM UTC-5, Terry Brown > > > wrote: > > > > > > Something I think you run into here is nodes vs. edges > > > (connections) carrying information. So two nodes are related: > > > > > > A -> B > > > > > > now you want to describe the relationship, "implements" (the > > > "source order" view) or "documents" or "todo_item" (issue / > > > ticket), whatever. > > > > > > Ok, so somehow you store those different flavors of relationship. > > > But now maybe you want to record priority, percent complete etc. on > > > the "todo_item" relation, or build documentation for different > > > contexts into the "documents" relationship. Suddenly describing a > > > relationship needs a complex data structure..., maybe some > > > hierarchy... > > > > > > So you end up in a situation where you could effectively use a node > > > to describe the relationship: > > > > > > A -> x -> B > > > > > > where if x is a node with its own children etc., there's no > > > restriction on how complex the description of the relationship > > > between A and B can be. > > > > > > And maybe you also have > > > > > > M -> x -> N and S -> x -> T where the relationships between A and > > > B, M and N, and S and T are all the same and described by the same > > > node 'x', so 'x' is a collecting point for nodes related in a > > > particular way. > > > > > > So Rob I'm not disagreeing with you or even perhaps responding to > > > what you're saying directly, just saying that I've seen "adding > > > descriptive elements to connections / edges / relationships" evolve > > > into "using nodes to describe connections" in the past. > > > > > > Cheers -Terry > > > > > > > > > ------------------------------ > > > *From:* Largo84 <[email protected]> > > > *To:* leo-editor <[email protected]> > > > *Sent:* Tuesday, February 16, 2016 2:35 PM > > > *Subject:* Attributes vs. Relationships > > > > > > I'm following with much interest the recent discussions on data > > > structures and possible new directions for Leo. Sorry in advance if > > > this new post hashes old ground, but it seemed to be somewhat of a > > > different approach (or question). > > > > > > It would be really cool to better expose the uA's and make them > > > truly useful. However, I see them as merely metadata (like tags in > > > media files). What would also be useful is to describe in some > > > meaningful way the *nature* of a data relationship between elements > > > (objects or 'nodes' in the Leo sense). Looking at the wikipedia > > > article on DAGs > > > <https://en.wikipedia.org/wiki/Directed_acyclic_graph>, I see the > > > directed vectors (arrows), but don't see how those describe what > > > the 'nature' of the relationship is between objects, just a > > > direction (of course, I may be missing something obvious). > > > > > > As an example, consider how MusicBrainz > > > <https://musicbrainz.org/doc/Work> describes advanced relationships > > > (ARs). A music track (like on a CD) may have a relationship with a > > > composition (work) and that relationship is described in a somewhat > > > 'symmetrical' way, such that the given work is 'related' to > > > multiple recordings and the track may be related to multiple > > > compositions (eg. medleys). These relationship 'descriptors' are > > > directional which prevents recursion problems. > > > > > > It seems to me that the only relationship inherent in the Leo data > > > model is one of Parent/Child (and maybe Sibling). I suppose that's > > > what makes it a DAG. Is it possible to describe other arbitrary > > > types of relationships between objects (nodes) that goes beyond > > > simply assigning a uA (tag) to a node. Maybe that uA may also be a > > > relationship 'type' that creates a 'link' between two or more > > > nodes. Maybe this also creates opportunities to create multiple > > > 'views' based on relationship types other than the native > > > Parent/Child. > > > > > > Rob...... > > > -- > > > 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 leo-editor+...@ googlegroups.com. > > > To post to this group, send email to [email protected]. > > > > > > Visit this group at https://groups.google.com/ group/leo-editor > > > <https://groups.google.com/group/leo-editor>. > > > For more options, visit https://groups.google.com/d/ optout > > > <https://groups.google.com/d/optout>. > > > > > > > > > -- > > > 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] <javascript:>. > > > To post to this group, send email to [email protected] > > > <javascript:>. > > > Visit this group at https://groups.google.com/group/leo-editor. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > > > > > > > -- 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.
