Single Tiddler storyview?

[TheDiveO]

I'm looking for a single tiddler storyview and I'm aware of the "zoomin" storyview. I've experimented with the zoomin storyview, but I see some obstacles to my particular usecase. Which is a TW used as a video library and player single-HTML app. I could have opted for Angular(JS), but then I really endore the TW core and modularity.

Alas, the obstacles:

1. Irritating animation -- is there some way to disable it short of rewriting the module? Please forgive me in case I've missed a configuration setting already there.
2. Block closing the last storyview tiddler (or reopen the start tiddler); there should be always a tiddler for my users to interact with, kind of a home tiddler.
3. Only render the topmost and thus visible tiddler. As a user navigates through the video library watching videos, the stack may contain several rendered (invisible) tiddlers with video players started and consuming many resources. Would it be possible to write a new single storyview to render only the topmost tiddler and discard any previously visible tiddler?

Best regards,
TheDiveO

[Birthe C]

To always have a tiddler open create $:/config/EmptyStoryMessage https://tiddlywiki.com/#HistoryMechanism 

Birthe

[TheDiveO]

Now that's useful, thank you very much! I've somehow missed that all the time. So my obstacle #2 is solved. https://tiddlywiki.com/#HistoryMechanism also helps me how with another question I had but didn't mentioned in my original post: a "back" button in each tiddler that should work similar to Android's back button as well as back buttons in Material Design apps.

Best regards,
TheDiveO

[BJ]

in the info tab of the control panel the animation duration can be set to zero to turn off animation.

I remember someone demoing a single tiddler storyview - I think they used a limit[1] in a filter but I cannot remember the exact details 

[TonyM]

Does setting the tiddlywiki to permaview to help back and forward.

Also use the topleftbar to always maintain something on a page to get someone out of trouble.

I will soon release my menu solution that could help provide a low impact access to features from a simple button in a single tiddler story.

Tony

[TheDiveO]

topleftbar? Do you refer to the tiddler controls or the right sidebar?

[TheDiveO]

Ah, that's what the animation parameter is for. So this fixes my obstacle #1. #2 was alsk already answered.

So your suggestion to use the limit/first filter operator sounds like an interesting hack to try out to get also #3 done.

Best regards,
Harald

[TheDiveO]

Unfortunately, the limit/first[1] hack in the storyriver template doesn't work as expected. Whenever a tiddler links to another tiddler down in the storyriver and you have managed to close that other tiddler then it won't get reopened.

Maybe it would be better to catch the navigation-related action messages, then open the new tiddler and close all others. Any idea how and where this would be to be implemented?

Oh, and I found the TopLeftBar -- I wasn't aware of it all the time up to now, so something else learnt.

Best regards,
TheDiveO

[TheDiveO]

A more detailed analysis of the TW5 core shows that the story river ($:/StoryList) is managed (at least) in two different places. One is the <$navigator> widget in the page template. The other place is a startup module that registers itself with any URL change events. This module then rewrites $:/StoryList whenever the URL changes its hash part, indicating which tiddlers to open. Luckily, this module also has a th-opening-default-tiddlers-list hook that allows changing or overwriting the story list before it gets activated.

As for the navigator widget, I'm afraid that I need to modify it in place using some bad bad module; in particular, I need to modify its saveStoryList and addToStory functions. Not nice.

[Jeremy Ruston]

Hi TheDiveO

It would be useful to have a proper single tiddler view. As you say, the key problem with the current zoomin view is the way that tiddlers other than the top one are still rendered, and hence impact performance.

We already have a precedent for attributes that customise the behaviour of the navigator widget. For the features you’ve described we could add two new attributes:

* singleTiddlerMode: “yes” causes the navigation handling to replace the entire story list with the target tiddler, instead of inserting it in the list

* openPreviousOnClose: “yes” causes the "close tiddler" handling to also re-open the previous tiddler in the history list, and pop it from the history list

A completely different approach would be to instead introduce a new “back” button in the tiddler toolbar as an alternative alongside the existing “close” button. It would send a “tm-back-tiddler” (?) message that would be handled by the navigator widget. It would respond by replacing the story list with the top title from the history list, and popping it from the history list.

I think I prefer the second approach because it avoids overloading the semantics of the “close” button; and with the modified behaviour we’re considering it would never actually close a tiddler.

Best wishes

Jeremy.

On 21 Jan 2018, at 17:42, TheDiveO <harald....@gmx.net> wrote:

A more detailed analysis of the TW5 core shows that the story river ($:/StoryList) is managed (at least) in two different places. One is the <$navigator> widget in the page template. The other place is a startup module that registers itself with any URL change events. This module then rewrites $:/StoryList whenever the URL changes its hash part, indicating which tiddlers to open. Luckily, this module also has a th-opening-default-tiddlers-list hook that allows changing or overwriting the story list before it gets activated.

As for the navigator widget, I'm afraid that I need to modify it in place using some bad bad module; in particular, I need to modify its saveStoryList and addToStory functions. Not nice.

--
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+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/dc04a768-f7f7-454c-8266-ebc5e4fed6c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[HansWobbe]

Many of my usecases would  benefit from the 2nd apprach that Jeremy described, so +1.  ~ Hans

On Sunday, January 21, 2018 at 3:48:32 PM UTC-5, Jeremy Ruston wrote:

...

I think I prefer the second approach because it avoids overloading the semantics of the “close” button; and with the modified behaviour we’re considering it would never actually close a tiddler.

...

 

[@TiddlyTweeter]

Ciao Jeremy & TheDiveO

I'm thinking here from the surface level of what would be useful to me.

Single (whole viewport) Tiddlers would seriously ease Slide Shows, Graphics Galleries, Presentations.

I can't conceive of these without Previous & Next navigation buttons.

I DO understand these "effects" could be, and have been, achieved, in numerous ways.

But I think there is much merit in simplifying things so its easier.

Best wishes
Josiah

[TheDiveO]

Hi Jeremy,

that sounds very much like what I would like to achieve! Like other have replied here, I very much prefer your second approach, and for the same reasons you list. Overloading close button semantic doesn't sound right for something that's not intended to be a quick hack. As for the message: this looks like a navigation message, not a tiddler-related message. So "tm-navigation-back" sounds more apt to me. And it rings the tm-navigation bell.

Best regards,
TheDiveO

[ste...@gmail.com]

Hi,

On Friday, January 19, 2018 at 5:59:17 PM UTC+1, TheDiveO wrote:

I'm looking for a single tiddler storyview and I'm aware of the "zoomin" storyview. I've experimented with the zoomin storyview, but I see some obstacles to my particular usecase. 

In addition to the suggestions from others, here are a few "hacks" I could think of:

1.) Replace the "close" button with the "home" button in your view toolbar (and make your start tiddler the "home" tiddler, obviously).

2.) Build a custom sidebar menu with something like the following code (it will close all other tiddlers whenever one of the links is clicked):

<$list filter="[tag[Contents]]">
<$button class="tc-btn-invisible tc-tiddlylink">
<$action-navigate $to={{!!title}}/>
<$action-sendmessage $message="tm-close-other-tiddlers" $param={{!!title}}/>
{{!!title}}
</$button>
<br/>
</$list>

Of course, this won't work with links from within your tiddlers. In this case, the other tiddlers will remain open, unless you use the code above for all your internal links.

Cheers,

Stef

[ste...@gmail.com]

On Monday, January 22, 2018 at 9:20:43 PM UTC+1, ste...@gmail.com wrote:

Of course, this won't work with links from within your tiddlers. In this case, the other tiddlers will remain open, unless you use the code from above for all your internal links.

One additional thought: Is there a way to (optionally!) enable this behavior for all internal links (to close all other tiddlers whenever a link is clicked)? Such an option would allow people to remove the "close" button from the view toolbar (and prevent anyone from accidentally ending up with an empty screen). 

Cheers,

Stef