[tw] Re: [TW5] Tidgraph - Easy tiddler graphs - New release candidate 0.9.0-rc1

[Tobias Beer]

Hi ihm,

Check the Custom Mode Demo at

https://ihm4u.github.io/tw5plugs/#Node%20Templates%20Demo

Cool! Thanks for picking up on this.
I'd perhaps make a slight "architectural" modification
where you'd not use the tiddler title directly for the mode
(because I wouldn't want those tiddlers in the "actual tiddlers" namespace:

So, you'd be using a field, maybe *_tgr_mode: mode-name*
and then go look for that tiddler when someone uses this mode.

This allows to stuff mode-config tiddlers into any namespace you want,
put them elsewhere, rename them, all that, while retainging functional
references.

Best wishes,

— tb

[i***@newsfromgod.com]

Hi Tobias,

Post by Tobias Beer
Cool! Thanks for picking up on this.
I'd perhaps make a slight "architectural" modification
where you'd not use the tiddler title directly for the mode
So, you'd be using a field, maybe *_tgr_mode: mode-name*
and then go look for that tiddler when someone uses this mode.
This allows to stuff mode-config tiddlers into any namespace you want,
put them elsewhere, rename them, all that, while retainging functional
references.

Great catch, I'll put it in the next release candidate.

Thanks so much for your insights. Let me know if you find bugs or
anyone reading this!
I would like for the release to be as clean as possible.

ihm

[Tobias Beer]

Hi ihm,

Post by Tobias Beer
So, you'd be using a field, maybe *_tgr_mode: mode-name*
and then go look for that tiddler when someone uses this mode.
This allows to stuff mode-config tiddlers into any namespace you want,
put them elsewhere, rename them, all that, while retaining functional
references.
After all, you're not going to create modes every day.

Many roads leading to Rome, here's another one.

You are probably aware of system tags. So, another way to model this could
be to...


1. set the tag *$:/tags/TidGraphMode* at a mode tiddler
2. specify the filter as its text
3. specify the mode name using a field like *mode:mode-name*

As you can see, this would require two steps to mark a tiddler as a
"mode-config tiddler", but it would be more in line with the core system
tagging approach. Well. Both ways are fine to me.

Best wishes,

— tb

[i***@newsfromgod.com]

Hi Tobias,

Post by Tobias Beer
Many roads leading to Rome, here's another one.
You are probably aware of system tags. So, another way to model this could
be to...
1. set the tag *$:/tags/TidGraphMode* at a mode tiddler
2. specify the filter as its text
3. specify the mode name using a field like *mode:mode-name*
As you can see, this would require two steps to mark a tiddler as a
"mode-config tiddler", but it would be more in line with the core system
tagging approach. Well. Both ways are fine to me.

hmm I prefer the other way, because mode tiddlers don't affect the
whole wiki. For example, $:/tags/Stylesheet makes the stylesheet
available for the whole wiki, same with $:/tags/Macro, or even the
other system tags which add new elements to the wiki layout. Also I
like one step less :) However I am all for keeping the user experience
in line with the core system, but in this case it doesn't seem to
match the idea of system tags, because Tidgraph modes don't affect the
whole system.

thanks!
ihm

[Tobias Beer]

Hi ihm,

Also I like one step less :)

Same here. Just thought I'd mention it. :)

Best wishes,

— tb

[i***@newsfromgod.com]

Hi,

Post by Tobias Beer
Hi ihm,

Also I like one step less :)

Same here. Just thought I'd mention it. :)
Best wishes,
— tb

Thanks for the tips! version 0.9.0-rc3 is out with the fixes we talked
about: the support for mode templates with a _tgr_mode field, and
support for _tgr_node_filter field in templates to select tiddlers to
which the template applies.

I also revamped the Node Templates Demos with more explanations and a
simple example like you suggested.

Let me know what you think of the new demo pages:

https://ihm4u.github.io/tw5plugs/#Node%20Templates%20Demo
and
https://ihm4u.github.io/tw5plugs/#Advanced%20Node%20Templates

And of course, I'd like to know if you find any bugs, especially with
the use of _tgr_node_level, _tgr_node_filter , _tgr_node_template,
_tgr_node_class, _tgr_node_class_add and of course _tgr_mode

Thanks!!

[Tobias Beer]

Hi ihm,

https://ihm4u.github.io/tw5plugs/#Node%20Templates%20Demo

Thanks, that looks a lot less complex.

One thing: I would recommend the same best practices for html in TiddlyWiki
as there exist for html in general.
One aspect being: Do not use inline styles (or inline js code).

So, I'd change the icon template at least like so:

<div class="icon-node">
<$transclude tiddler={{!!icon}}/>
<$link>{{!!title}}</$link>
</div>
<style>
.icon-node{display:table;margin:0 auto;}
.icon-node > a {display: table-cell;vertical-align: middle;}
</style>

In fact, I'd even take out the styles entirely and encourage using a custom
stylesheet tiddler tagged *$:/tags/Stylesheet*.

And of course, I'd like to know if you find any bugs, especially with
the use of _tgr_node_level, _tgr_node_filter , _tgr_node_template,
_tgr_node_class, _tgr_node_class_add and of course _tgr_mode

Looking at the actual html for the first time...

I'm seeing a lot of elements here and I'm not sure all are needed, both
elements and classes.
Thinking it is always good to keep it to the bare minimum.

Right now you have...

<table>
<tr>
<td rowspan="1">
<div class="ihm-tgr-node-container" id="1447833368596-Honesty" title="whereby
one loves the beauty of temperance">
<div class="ihm-tgr-node tgr-node"><a class="tc-tiddlylink
tc-tiddlylink-resolves" href="#Honesty">Honesty</a>
</div>
</div>
</td>
</tr>
...
</table>

The first thing I see is you're using tables.
Was that a design choice or a necessity?
I believe this imposes quite strong, and hopefully unnecessary design
constraints.

So, instead of a simple nesting like you have...

<table>
<tr>
<td>
<div class="ihm-tgr-node-container">
<div class="ihm-tgr-node tgr-node">
<table>
<tr>
<td>
<div class="ihm-tgr-node-container">
<div class="ihm-tgr-node tgr-node tgr-node-level-1"/>
</div>
</td>
</tr>
</table>
</div>
</div>
</td>
</tr>
</table>

Why not just do...

<div class="tgr-node-group">
<div class="tgr-node">
<div class="trg-node-group">
<div class="trg-node">
</div>
</div>
</div>
</div>

?

After all, you can always make a div behave as if having a table-layout.
The other way around doesn't seem to be quite the case.

I imagine that, wanting to introduce different layouts,
this is the first thing where tables will complicate things quite
unnecessarily,
or even make things quite impossible (e.g. "needs to be in one row").

Best wishes,

— tb

[i***@newsfromgod.com]

Hi Tobias,

Post by Tobias Beer
Hi ihm,

https://ihm4u.github.io/tw5plugs/#Node%20Templates%20Demo

Thanks, that looks a lot less complex.

Great!

Post by Tobias Beer
One thing: I would recommend the same best practices for html in TiddlyWiki
as there exist for html in general.
One aspect being: Do not use inline styles (or inline js code).
<div class="icon-node">
<$transclude tiddler={{!!icon}}/>
<$link>{{!!title}}</$link>
</div>
<style>
.icon-node{display:table;margin:0 auto;}
.icon-node > a {display: table-cell;vertical-align: middle;}
</style>

Alright, will do this asap

Post by Tobias Beer
Looking at the actual html for the first time...
The first thing I see is you're using tables.
Was that a design choice or a necessity?

It is a design choice to allow the browser to do most of the layout.
This is very important
because it is almost impossible to cater for all the different layout
changing events that
occur during the normal usage of the browser.

However, I could use simplified layout with divs, I'll look into that.

]> Why not just do...

Post by Tobias Beer
<div class="tgr-node-group">
<div class="tgr-node">
<div class="trg-node-group">
<div class="trg-node">
</div>
</div>
</div>
</div>

It is important to have the ihm-* classes, the idea for them is to
provide certain styles
that need to be there for the whole layout to work. the tgr-* classes
which don't have ihm in
it can be replaced or changed by the user. This was the original idea,
but I also needed to
provide default graphical styles with the plugin, and so I prefixed
those default classes with ihm also.

With node templates things have become much easier, because you just
use the _tgr_node_class_add field
if you want to add a class to the existing default behaviour, or
_tgr_node_class if you want to replace the existing default class.

Post by Tobias Beer
?
After all, you can always make a div behave as if having a table-layout.
The other way around doesn't seem to be quite the case.

Yes, divs are much better...

Post by Tobias Beer
I imagine that, wanting to introduce different layouts,
this is the first thing where tables will complicate things quite
unnecessarily,
or even make things quite impossible (e.g. "needs to be in one row").

Yes, as I look into the vertical layout for Sylvain I am tending to
think that divs will make
that easier...

BTW, I had an idea about the mode configuration. Wouldn't it be
better, easier and much cleaner to have:

$:/config/tidgraph/modes/my-mode-name as the tiddler for the mode
configuration? This would even be one step less than before (no need
for _tgt_mode field) and make it much easier and in concert with
general Tiddlywiki usage. I think you had mentioned it once, but I
lost the idea in the midst of the other work with node templates.

what do you think?

Thanks!

[Tobias Beer]

Hi ihm,

I also needed to provide default graphical styles with the plugin, and so
I prefixed those default classes with ihm also.

So, you need some classes that are always there.
It's just that they appear at the same items that also have classes that
are eventually user defined in a node-template.
Wouldn't that also remove your ihm classes? Are they functionally required
or simply providing default styles (and which)?

$:/config/tidgraph/modes/my-mode-name as the tiddler for the mode

configuration?

I think it's perfectly fine to extract available templates as those
matching *[prefix[:/config/tidgraph/modes/]]*.
The important thing being that the user never has to specify the long title.

Best wishes,

— tb

[i***@newsfromgod.com]

Hi Tobias,

Post by Tobias Beer
Hi ihm,
    So, you need some classes that are always there.
    It's just that they appear at the same items that also have classes
that are eventually user defined in a node-template.
    Wouldn't that also remove your ihm classes? Are they functionally
required or simply providing default styles (and which)?

Besides custom classes in node templates, the only supported classes for
modification are the ones in the documentation:

* tgr-node for the node
* tgr-link for the svg connector
* tgr-arrow for the svg arrow

All the other classes are either required or a default graphic style.

Post by Tobias Beer
 

Post by i***@newsfromgod.com
$:/config/tidgraph/modes/my-mode-name as the tiddler for the mode
configuration?

     
    I think it's perfectly fine to extract available templates as those
matching [PREFIX[:/CONFIG/TIDGRAPH/MODES/]].
    The important thing being that the user never has to specify the

long

Post by Tobias Beer
title.

Done, rc4 is out .. I think we finally came to a good solution for this
one.

To install go to:
https://ihm4u.github.io/tw5plugs/

thanks!!

[Linus Johnsson]

Hi ihm,

I really like the idea of a lightweight tree/graph plugin and Tidgraph
surely looks promising!

I don't know if this is the right place to ask for new features (forgive me
if it isn't), but I can't help feeling that Tidgraph would benefit from an
even more flexible graph traversing algorithm. Specifically, I would love
to see something like "weak links" being implemented alongside the tree
structure (which I consider being constituted by "strong links"). Ideally,
the user would define the semantics of "weak links" through a filter.

Some possible conceptions of weak links that I would find very useful:

- a relationship between two nodes that tag a common intermediary: N ->
I <- N
- a between two nodes that tag one intermediary each, where the
intermediaries are linked through a tagging relationship in either
direction: N -> I -> I <- N
- any of the above, where the intermediaries are subject to additional
conditions (for instance, have a certain tag).

Weak links would of course need to be visually distinct from strong links,
for instance by using dashed arrows.


Any thoughts on this?


Best regards,

Linus

Hi,
This is a new version of Tidgraph with new and exciting features! It
has the ability to make *custom node templates thanks to Tobias Beer*. It
is a release candidate, since I want to make sure I didn't introduce some
bugs and to get some comments from the community before I make the main
release.
* Node templates!! (many thanks to Tobias!)
* Custom user modes with subfilters ( Tobias again! ☺ )
* Support field list in nodetitle (first non-empty field is used)
* No output for non-existent tree root
* Fix handling of missing children
* Minor bugfixes
https://ihm4u.github.io/tw5plugs/#Tidgraph%20-%20Easy%20tiddler%20graphs%20for%20TW5
Node templates are a tremendous feature, since they allow you to share
your templates with others.
Please let me know if you find any bugs, most especially regressions.
The documentation is not there yet, but I will put it together before the
main release. However you can see the
https://ihm4u.github.io/tw5plugs/#Node%20Templates%20Demo to get an idea.
Thanks!!
ihm

[Tobias Beer]

Hi Linus,

Glad to say that *ihm* has already implemented this.
You will find it under what we called "modes
<https://ihm4u.github.io/tw5plugs/#Custom%20Mode%20Demo>".

Here's a long list of proposals I made earlier:

- https://groups.google.com/d/msg/tiddlywiki/3gXQKj2rIEY/sS1jmQVxAwAJ
- https://groups.google.com/d/msg/tiddlywiki/3gXQKj2rIEY/ukJVXRNyAwAJ

...of which *ihm* has already implemented *node templates* and *modes*.
Yay. :-)

Best wishes,

— tb

[i***@newsfromgod.com]

Post by Tobias Beer
Hi ihm,
I really like the idea of a lightweight tree/graph plugin and Tidgraph
surely looks promising!
I don't know if this is the right place to ask for new features (forgive me
if it isn't), but I can't help feeling that Tidgraph would benefit from an
even more flexible graph traversing algorithm. Specifically, I would love
to see something like "weak links" being implemented alongside the tree
structure

Like Tobias said, this is already implemented (but no, you don't need
to use "modes" to do this)
simply tag or link your tiddlers as you want and the graph will show it.

I have updated the main page with an example that shows this kind of
non-tree/weak links.

Post by Tobias Beer
Weak links would of course need to be visually distinct from strong links,
for instance by using dashed arrows.

This is great, I had not thought about it. Those kinds of links should
be visually distinct by
default, so I have already implemented it in 0.9.3

Download it at
https://ihm4u.github.io/tw5plugs/#Tidgraph%20-%20Easy%20tiddler%20graphs%20for%20TW5

Post by Tobias Beer
Any thoughts on this?

It's already done :) hehehe

Post by Tobias Beer
Best regards,
Linus

[Alex Hough]

It would be nice if , in vertical mode, the top node opened above current
tiddler, and the children below

great wotk!

Ale

Post by Tobias Beer
Hi ihm,

Post by Linus Johnsson
I really like the idea of a lightweight tree/graph plugin and Tidgraph
surely looks promising!
I don't know if this is the right place to ask for new features (forgive me
if it isn't), but I can't help feeling that Tidgraph would benefit from an
even more flexible graph traversing algorithm. Specifically, I would love
to see something like "weak links" being implemented alongside the tree
structure

Like Tobias said, this is already implemented (but no, you don't need to
use "modes" to do this)
simply tag or link your tiddlers as you want and the graph will show it.
I have updated the main page with an example that shows this kind of
non-tree/weak links.
Weak links would of course need to be visually distinct from strong links,

Post by Linus Johnsson
for instance by using dashed arrows.

This is great, I had not thought about it. Those kinds of links should be
visually distinct by
default, so I have already implemented it in 0.9.3
Download it at
https://ihm4u.github.io/tw5plugs/#Tidgraph%20-%20Easy%20tiddler%20graphs%20for%20TW5

Post by Linus Johnsson
Any thoughts on this?

It's already done :) hehehe

Post by Linus Johnsson
Best regards,
Linus

--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/20151119134415.Horde.5VES6TVZuVkDUMOgbTvcwIO%40www.newsfromgod.com
.
For more options, visit https://groups.google.com/d/optout.

[Tobias Beer]

Hi Alex,

Post by Alex Hough
It would be nice if , in vertical mode, the top node opened above current
tiddler, and the children below

I think it's not so much about the parent but about the current tiddler,
actually. Perhaps it could be given some *_tgr-current-tiddler* class...
which can then be styled if desired.

Best wishes,

— tb

[i***@newsfromgod.com]

Hi Alex/Tobias,

Post by Tobias Beer

Post by Alex Hough
It would be nice if , in vertical mode, the top node opened above current
tiddler, and the children below

I think it's not so much about the parent but about the current tiddler,
actually. Perhaps it could be given some *_tgr-current-tiddler* class...
which can then be styled if desired.
Best wishes,

hmm..I really don't understand what you are discussing here...maybe a
picture?

thanks!

[Tobias Beer]

Hi ihm,

I really don't understand what you are discussing here...maybe a picture?

<Loading Image...>

Best wishes,

— tb

[i***@newsfromgod.com]

Hi Tobias,

Post by Tobias Beer
Hi ihm,

I really don't understand what you are discussing here...maybe a picture?

<https://lh3.googleusercontent.com/-WY6lMZaKh3Y/Vk5XoeNJdvI/AAAAAAAAB7Q/KPmmMNdF5ZI/s1600/strong_weak.jpg>
Best wishes,
— tb

I wasn't referring to Linus post, but to Alex's comment about the
vertical layout...I don't understand what you were discussing with him

thanks
ihm

[Tobias Beer]

Hi ihm,

Post by i***@newsfromgod.com
I wasn't referring to Linus post, but to Alex's comment about the
vertical layout...I don't understand what you were discussing with him

Sorry, 'bout that. The moments we're not paying attention, mhhh.

So, I think Alex wanted for the current tiddler to stand out more, so he
proposed to center its parent node (should there be one) next to it, which
is one way to do it, but sounds very complicated to achieve.

As an alternative, I suggested to simply highlight the current tiddler in
the graph, i.e. to just give it a css class "tgr-current-tiddler".

Here's what that looks like, provided I understood Alex right:

<Loading Image...>

Best wishes,


— tb

[i***@newsfromgod.com]

Hi,

Post by Tobias Beer
So, I think Alex wanted for the current tiddler to stand out more, so he
proposed to center its parent node (should there be one) next to it, which
is one way to do it, but sounds very complicated to achieve.

Yes, that is too complicated

Post by Tobias Beer
As an alternative, I suggested to simply highlight the current tiddler in
the graph, i.e. to just give it a css class "tgr-current-tiddler".

Yes, this is easy to do with node templates.

1. Make a node template with a field _tgr_node_filter set to [all[current]]
2. Insert a _tgr_node_class_add field with the CSS class the he'd like
for the current tiddler (just changing the background color will work,
because _tgr_node_class_add keeps the default class and adds the new
one)
3. Add a link or whatever is wanted to the content of the template

Post by Tobias Beer
<https://lh3.googleusercontent.com/-RM3ySqHrNgs/Vk7L7aVVqJI/AAAAAAAAB7o/nMElLfqXNpA/s1600/current.jpg>
Best wishes,

Thanks for that, that makes it very clear.

ihm

[Felix Küppers]

Post by i***@newsfromgod.com
This is great, I had not thought about it. Those kinds of links should
be visually distinct by
default, so I have already implemented it in 0.9.3
Download it at
https://ihm4u.github.io/tw5plugs/#Tidgraph%20-%20Easy%20tiddler%20graphs%20for%20TW5

Post by Linus Johnsson
Any thoughts on this?

It's already done :) hehehe

Very nice!

[Linus Johnsson]

ihm and Tobias, thanks for your kind replies. However, I'm not sure that I
completely understand how this works just yet.

First of all, how does the engine know which links are "strong" and which
are "weak"? In ihm's example, why is "Purity" a child of "Temperance"
rather than of "to truly love your Spouse"? After all, both "Temperance"
and "to truly love your Spouse" tag "Purity". I suspect that the ambiguity
is resolved by something like a breadth-first search, where the
"Temperance" -> "Purity" relationship gets priority because its closer to
the root. But this would not necessarily work for more complex scenarios.
Were "to truly love your Spouse" to have a child which in turn were to have
a weak link to "Purity", it would surely fail.

Second, given my example where N1, N2 and I are nodes and x -> y means that
x tags y, how would I declare that N1 -> I <- N2 be interpreted as a weak
link between N1 and N2? The way I understand your widget, it would display
the intermediary I as a node, which is not what I want.

Best regards,
Linus

Post by Tobias Beer
Hi ihm,

Post by Linus Johnsson
I really like the idea of a lightweight tree/graph plugin and Tidgraph
surely looks promising!
I don't know if this is the right place to ask for new features (forgive me
if it isn't), but I can't help feeling that Tidgraph would benefit from an
even more flexible graph traversing algorithm. Specifically, I would love
to see something like "weak links" being implemented alongside the tree
structure

Like Tobias said, this is already implemented (but no, you don't need to
use "modes" to do this)
simply tag or link your tiddlers as you want and the graph will show it.
I have updated the main page with an example that shows this kind of
non-tree/weak links.
Weak links would of course need to be visually distinct from strong links,

Post by Linus Johnsson
for instance by using dashed arrows.

This is great, I had not thought about it. Those kinds of links should be
visually distinct by
default, so I have already implemented it in 0.9.3
Download it at
https://ihm4u.github.io/tw5plugs/#Tidgraph%20-%20Easy%20tiddler%20graphs%20for%20TW5

Post by Linus Johnsson
Any thoughts on this?

It's already done :) hehehe

Post by Linus Johnsson
Best regards,
Linus

--
You received this message because you are subscribed to a topic in the
Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/tiddlywiki/Iq637aAW-OI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/20151119134415.Horde.5VES6TVZuVkDUMOgbTvcwIO%40www.newsfromgod.com
.
For more options, visit https://groups.google.com/d/optout.

[Tobias Beer]

Hi Linus,

ihm and Tobias, thanks for your kind replies. However, I'm not sure that I

Post by Linus Johnsson
completely understand how this works just yet.

Please ignore my response, I completely misread your request.

As for those neat "weak links", my first guess would be
that they are at a lower level than "strong links" with respect to the root
node.

Come to think of it, having them should perhaps be optional.

I believe the documentation for what those "weak links" are and how they
work is still missing.
So, that feels a bit like a teaser, tbh. :D

Best wishes,

— tb

[Linus Johnsson]

Hi Tobias,

I believe that a meaningful conception of weak links cannot assume that any
weak link is more distant from the root node than the strong link with
which it competes for "parental priority" (although admittedly that might
be the most prevalent case). I see weak links as a semantically distinct
concept. For me, defining them through untraversable intermediaries would
make most sense, but I'm sure that others might come up with other use
cases. Hence, allowing the user to specify a filter that identifies weak
link targets would be a nice and flexible solution.

Best regards,
Linus

Post by Tobias Beer
Hi Linus,
ihm and Tobias, thanks for your kind replies. However, I'm not sure that I

Post by Linus Johnsson
completely understand how this works just yet.

Please ignore my response, I completely misread your request.
As for those neat "weak links", my first guess would be
that they are at a lower level than "strong links" with respect to the
root node.
Come to think of it, having them should perhaps be optional.
I believe the documentation for what those "weak links" are and how they
work is still missing.
So, that feels a bit like a teaser, tbh. :D
Best wishes,
— tb
--
You received this message because you are subscribed to a topic in the
Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/tiddlywiki/Iq637aAW-OI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/9c07ac15-0df5-440f-bdb4-b35e5380e8c1%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/9c07ac15-0df5-440f-bdb4-b35e5380e8c1%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Tobias Beer]

Hi Linus,

I see weak links as a semantically distinct concept.

For me, defining them through untraversable intermediaries would make most

sense, but I'm sure that others might come up with other use cases. Hence,
allowing the user to specify a filter that identifies weak link targets
would be a nice and flexible solution.

I believe what you describe is like a "secondary" filter — compared to the
"primary" mode filter — that links "even more related" nodes based on a
different kind of (which?) relationship, possibly displaying different
edges, as we're now seeing a different kind of relation.

Not exactly sure how you picture those displayed in a tidgraph. What you
could do is use a custom node-template that shows one or more secondary
list for more related tiddlers... which you could even chuck into
sliders... something that perhaps looks like MagicTabs.

——————————————————————
| *title *|
——————————————————————
| *icon* | icon | icon |
——————————————————————
| * *secondary 1* |
| * *secondary 2* |
——————————————————————

Maybe I'm mistaken, but creating the above as a custom node-template should
already be possible.
So, there's possibly nothing much for *ihm* to do.

However, I would perhaps not overload a graph too much.

Best wishes,

— tb

[Tobias Beer]

Hi again, Linus,

I see weak links as a semantically distinct concept.

Ah, now I get it... perhaps.

While my proposal above may be useful too, I guess you'd like to display
another type of *edge *in the current graph that is established via some
secondary relationship filter evaluated against any nodes in the graph...
and only displays secondary edges for items that are already part of the
"primary" graph.

Well, if *ihm* allowed a secondary edge-type, then he may actually allow to
define any number of secondary edge types ...and then have some legend on
the side / below where you can perhaps toggle all available edges in
the graph.

So, the secondary edges may simply be an enumeration of "secondary
modes"... each defined via its own config tiddler.

Best wishes,

— tb

[i***@newsfromgod.com]

Hi,

Post by Tobias Beer
So, the secondary edges may simply be an enumeration of "secondary
modes"... each defined via its own config tiddler.

Right, a list of modes with the first one defining the tree structure
and the others adding
their own layer of edges to already existing nodes.

Post by Tobias Beer
Best wishes,
— tb
--
You received this message because you are subscribed to the Google
Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it,
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/0801d21a-3dd4-4760-bd6c-04c67612cc78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[i***@newsfromgod.com]

Hi Tobias,

Post by Tobias Beer
I believe the documentation for what those "weak links" are and how they
work is still missing.
So, that feels a bit like a teaser, tbh. :D

Actually, it is very simple. The question is what do you do if a
tiddler is tagged by two or more tiddlers that are in different places
in the tree? Which one do you use as the node under which the tiddler
will show up?

The answer which works very well in all normal cases is to choose the
parent that is closes to the root, and draw a link to the other parent
tiddler (this second link is drawn with a dashed curve). The graph
represents the reality of your tiddler structure. If the tiddler has
two parents, then it will show two links, if it has three it will show
three links.

But only one of those links will be considered the 'main' one. The one
that goes to the parent that is closes to the root. All the other
links are considered 'weak'.

Users don't have to worry about it, they simply need to know that the
tree truly shows the structure of their tiddlers.There is no option to
set or anything to do for the user, the graph will simply show the
true relationship between the tiddlers.

The case of Linus is a bit of a different one, because he wants to
model a semantically different relation between the nodes. It is a
good use case for special domains like the research he was mentioning.
If he writes a javascript filter it is not hard for me to add support
for layered modes which will allow what he wants without affecting any
of the architecture or the normal users out there.

My guess is that only few very specialized people will use that kind of thing.

thanks
ihm

Post by Tobias Beer
Best wishes,
— tb
--
You received this message because you are subscribed to the Google
Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it,
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/9c07ac15-0df5-440f-bdb4-b35e5380e8c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[i***@newsfromgod.com]

Post by Linus Johnsson
ihm and Tobias, thanks for your kind replies. However, I'm not sure that I
completely understand how this works just yet.
First of all, how does the engine know which links are "strong" and which
are "weak"? In ihm's example, why is "Purity" a child of "Temperance"
rather than of "to truly love your Spouse"? After all, both "Temperance"
and "to truly love your Spouse" tag "Purity". I suspect that the ambiguity
is resolved by something like a breadth-first search, where the
"Temperance" -> "Purity" relationship gets priority because its closer to
the root.

Yes, a breadth-first search is the way in which this is solved

Post by Linus Johnsson
But this would not necessarily work for more complex scenarios.
Were "to truly love your Spouse" to have a child which in turn were to have
a weak link to "Purity", it would surely fail.

The user does not specify 'weak links' but only child/parent relationships.
Tidgraph computes which links are weak and which are strong by giving priority
to those closest to root as you intelligently found out.

Make a child of 'to truly love your Spouse' and tag that child
with "Purity". You will see that the child is now closer to "Purity" because
that position is closer to root. It works fine. The only thing is that
you can't see
the arrow very well because it covered by the collapse button.

Post by Linus Johnsson
Second, given my example where N1, N2 and I are nodes and x -> y means that
x tags y, how would I declare that N1 -> I <- N2 be interpreted as a weak
link between N1 and N2? The way I understand your widget, it would display
the intermediary I as a node, which is not what I want.

In this case you want Tidgraph to create a 'third link' which is weak, between
N1 and N2 because they are connected through an intermediary node. I
don't think
I will support this kind of feature directly, because it engages on
interpreting
the semantics of the connections. I can imagine that for some node
combinations
you may want the 'third link' and not for others.

You may be able to do what you want by writing your own javascript
filter and using that
as a Custom Mode.Also, I suggest you try TiddlyMap, it is designed for complex
trees and allows many kinds of links in one widget.

Post by Linus Johnsson
Best regards,
Linus

[Linus Johnsson]

Thanks, ihm, that clarifies things. I still strongly believe that
implementing weak links (phantom links?) that are semantically distinct
from parent-child relationships would be worthwhile. Case in point:
Qualitative researchers might sometimes want to be able to model processes,
which are composed of causal relationships, in addition to conceptual
relationships. But I fully understand if you hesitate to mess with a system
that works.

I'm unfortunately not proficient in JS (yet!) but I might take your advice
some time in the future. I did try TiddlyMap, but regrettably it slowed my
Wiki down to a crawl.

Best regards,
Linus

Post by Linus Johnsson
ihm and Tobias, thanks for your kind replies. However, I'm not sure that I

Post by Linus Johnsson
completely understand how this works just yet.
First of all, how does the engine know which links are "strong" and which
are "weak"? In ihm's example, why is "Purity" a child of "Temperance"
rather than of "to truly love your Spouse"? After all, both "Temperance"
and "to truly love your Spouse" tag "Purity". I suspect that the ambiguity
is resolved by something like a breadth-first search, where the
"Temperance" -> "Purity" relationship gets priority because its closer to
the root.

Yes, a breadth-first search is the way in which this is solved
But this would not necessarily work for more complex scenarios.

Post by Linus Johnsson
Were "to truly love your Spouse" to have a child which in turn were to have
a weak link to "Purity", it would surely fail.

The user does not specify 'weak links' but only child/parent relationships.
Tidgraph computes which links are weak and which are strong by giving priority
to those closest to root as you intelligently found out.
Make a child of 'to truly love your Spouse' and tag that child
with "Purity". You will see that the child is now closer to "Purity" because
that position is closer to root. It works fine. The only thing is that you
can't see
the arrow very well because it covered by the collapse button.

Post by Linus Johnsson
Second, given my example where N1, N2 and I are nodes and x -> y means that
x tags y, how would I declare that N1 -> I <- N2 be interpreted as a weak
link between N1 and N2? The way I understand your widget, it would display
the intermediary I as a node, which is not what I want.

In this case you want Tidgraph to create a 'third link' which is weak, between
N1 and N2 because they are connected through an intermediary node. I don't
think
I will support this kind of feature directly, because it engages on
interpreting
the semantics of the connections. I can imagine that for some node
combinations
you may want the 'third link' and not for others.
You may be able to do what you want by writing your own javascript filter
and using that
as a Custom Mode.Also, I suggest you try TiddlyMap, it is designed for complex
trees and allows many kinds of links in one widget.

Post by Linus Johnsson
Best regards,
Linus

--
You received this message because you are subscribed to a topic in the
Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/tiddlywiki/Iq637aAW-OI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/20151119172659.Horde.INkuEaTltdspgwUOYCB7rB1%40www.newsfromgod.com
.
For more options, visit https://groups.google.com/d/optout.