[IDEA] Affordance for some storyviews to be excluded from the story view switcher

[saqimtiaz]

storyviews are a versatile way to add behaviour/animation to the output of a $list widget. However, not all storyviews may be appropriate for use with the default story river in TiddlyWiki.

It would therefore be helpful to have an affordance for excluding some storyviews from the storyview switcher used to choose the storyview for the default story river.

My preferred approach would be to tweak the filter used by the storyview switcher snippet to exclude storyviews based on a criteria like a leading underscore in the storyview name. https://github.com/Jermolene/TiddlyWiki5/blob/ac022ec79f05715f62fd8382ebb6b49cd1c8f960/core/wiki/viewswitcher.tid#L8 Could be changed to: <$list filter="[storyviews[]!prefix[_]]" variable="storyview">

Alternatively we could tweak the storyviews[] operator to exclude storyviews based on the same criteria. However, it would be more appropriate for the filter operator to show all available storyviews and for the UI component to filter out the ones not appropriate to its context.

[pmario]

In the GG and may be at Talk, we did already "suggest" the _-prefix to users for their somewhat "special" tiddlers, because they are automatically sorted at the "top of the list" in the More : All tab. ...

So using it in the core imo is a bit of a "name clash"

just a thought.

[saqimtiaz]

@pmario alternatives to the _ prefix idea are very welcome and the reason why this has been framed as an issue rather than a PR.

Do note however that in this context we are referring to the name of a storyview and not the name of a tiddler.

[Jermolene]

Hi @pmario the precedent is that the core already uses an underscore as a prefix for fields that have behaviours that are loosely defined by the core: _canonical_uri and _is_skinny. In this case, of course, end users are rarely going to be creating storyviews.

[pmario]

Hi @pmario the precedent is that the core already uses an underscore as a prefix for fields that have behaviours that are loosely defined by the core: _canonical_uri and _is_skinny. In this case, of course, end users are rarely going to be creating storyviews.

@Jermolene ... I think it's time to make a decision about "system related prefixes". ... From time to time we do create new "system fields" like the code-body field. Since there hasn't been any decision it ended up to be un-prefixed and now "clutters" user field namespace.

Since @saqimtiaz suggests underline in the OP I think he would be fine with it. I would be OK with it too. .. So if you say "underline it is", it would be a decision we could live with.

---

We would only need to define, what makes a new field a "system field". May be a different discussion.

From my point of view the rules may be:

• If a something causes special handling in any core template it should be prefixed with an underline.
• If a something-name is hardcoded in JS code it should be prefixed
• There may be some exceptions for backwards compatibility reasons
  • listed at: https://tiddlywiki.com/#TiddlerFields
    • some of those fields may be deprecated and converted to fields with an underline ...eg: hide-body

[Jermolene]

Hi @pmario this PR is about the names of storyviews, not fields. I think your proposal needs a new ticket. As it happens, my view is the underscore prefix is for fields whose usage is defined in the core JS code, and not merely for fields mentioned in the core templates (which I think would include things like "hide-body").

Going back to the storyviews issue at hand, another way to approach it might be to add explicit metadata to storyviews. It could be as simple as a new filter operator, for example [[mystoryview]getstoryviewmetadata[is-listed]] to retrieve the "is-listed" status of a storyview.