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 tiddlywiki+unsubscr...@googlegroups.com. To post to this group, send email to tiddlywiki@googlegroups.com. Visit this group at http://groups.google.com/group/tiddlywiki. For more options, visit https://groups.google.com/d/optout.