Hi Alberto,
*that way, annotation tiddlers can be first class citizens*, having their
> own dedicated tabs, view templates, etc. For instance, you may want a tab
> specific to video annotations showing related with the same topic, or
> documentation tiddlers talking about the same topic as the video
> annotation.
>
Being tiddlers, annotations already are "first class citizens"... in
TiddlyWiki.
So, what we magically desire are dedicated tabs that only show for certain
citizens.
The question perhaps remains: What produces triggers a tab showing?
What identifier is used to trigger showing a tab?
To me, that is always some filter expression ...which we could associated
with a tiddler tagged something like *$:/tags/MagicTab*.
A filter that is perhaps not even stored at that tab-tiddler directly, so
as to decouple switching it on and off from the actual template.
> if you create the tiddler $:/type/annotation with a caption, an icon, a
> template, they are automatically used by the macros <<tabCaption>> and
> <<inputSlider>>.
>
The core would probably do this via individual tiddlers, like...
- *$:/mt/types/<type-name>/tab*
- the tab template
- *$:/mt/types/<type-name>/icon*
- the icon for the thing
- *$:/mt/types/<type-name>/field*
- a (list) field that triggers showing the tab
- *$:/mt/types/<type-name>/tag*
- a tag that triggers showing the tab, in the form of *$:/type/<tag>*
- *$:/mt/types/<type-name>/filter*
- an entirely custom filter that triggers showing the tab
- *$:/mt/types/<type-name>/lingo/en-GB/caption*
- a caption for a given language, fallback being *en-GB*
...this ensures that core components only get partially overwritten but not
completely, which would prevent getting template updates later on. So, for
each tab, there would be a set of the above, perhaps all of which are
optional, thus showing the tab for all tiddlers.
How about something more implicit, like...
>>
>> *$:/type/**field/**yt-id*
>>
>
> Sorry, I don't understand your point.
>
The point was to trigger showing a tab not based on the presence of a
certain tag,
but rather based on the presence of a certain field that would be used
anyway... for a "typed citizen".
The filter to show/hide tabs would possibly be able to handle both cases in
one, e.g.
show either when...
- tagged *$:/type/<type-name>*
- field *mt-type *= *<type-name>*
You need a qualified relationship between the video and its annotations,
> and the *yt-video* field works. You could use in the same way I use the
> *source* field. But if you use yt-video instead of source, you need to
> create specific list filters while source is used by default in MagicTabs.
>
Yes, so I'm thinking it does have to be a field, after all, rather than a
tag.
Custom list fields are a pain in the neck. But I managed to have them
> working with fields like *authors*, *about*, *parent*, and I don't
> remember if *source*.
>
They may be a pain in the neck, but I think for harmony's sake, all those
relatiohship fields should be handled using list-fields and the kind of
nomenclature that is required for them to work properly, be it a 1:many
relationship or a mere 1:1... and one day, hopefully, the same ui as is
given to the *tags* field... plus the ordering.
Best wishes, Tobias.
--
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 email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
