The plugin. Just like it has author, description, version, etc. fields
Thanks @Scott_Sauyet for a nice navigation plugin and the useful questions about plugin production too. Both will assist future navigators!
One request for a future iteration - a config option to choose whether to close the current tid when clicking on ‘previous’ or ‘next’. At the moment they all seem to remain open in the river.
1 Like
It’s ok Scott, I answered my own question by going to Control panel, Appearance, Story view, Zoomin. Allows only one tid at a time.
Turning the animation setting under the ‘info’ tab down to 0 also helped.
May still be a nice plugin config option for other views but it works well for me now, thanks!
[quote=“Mark_S, post:11, topic:5376”]
Oh, of course. I copied that info file from somewhere and either I accidentally deleted name or it wasn’t there. Added in the new version below.
Hmm, I don’t know how to do that yet. I could certainly look, but I thought that was basically controlled at the wiki level, with $:/view, configurable from Control Panel > Appearance > Story View. Is there another level of control?
Another new version adds the missing name property and changes the Tag footer from <ul> to <ol>:
3 Likes
Hi @Scott_Sauyet
Two more ‘config option’ questions for a future iteration, should you find time for refinements;
Can I change the sort order on the ‘next’ and ‘previous’ titles? At the moment they’re sorted alphabetically by title. I’d like to be able to step through by date created or any other field.
Can I replace the title links displayed for ‘next’ and ‘previous’ with something else? E.g arrow icons or contents of another field. The link would remain the same. Same for the Wizard list, I’d like to sort it differently.
Both might already be possible by tweaking some filters but nice to have as config options too.
Thanks for the plugin Scott!
Oh, I’m still working on refinements. There’s a long thread where I’ve been asking about how I might achieve one refinement I would like to have. The consensus seems to be that if it’s even possible it’s extremely tricky, and beyond my current skills.
They’re currently sorted by the list field on the TagTiddler, if it has one, and by the natural alphabetic ordering otherwise. You can change the list field by clicking on a Tag Pill and dragging the fields around. You’re right that it might make sense to offer a way to override the sorting, but I’ll have to think about it. If you’re comfortable with GitHub, could you raise an issue for this?
At the moment you can simply override the ViewTemplate. That long issue was all about how to make this overridable in a more user-friendly way. I think that’s playing itself out now, but if it comes down to, “No, that can’t be done by a noob like you,” then I’ll look at how this might be configured. It doesn’t sound too hard.
I raised an issue on github about enabling ‘next’ and ‘previous’ to sort on a field other than title but I think I’ve answered my own question.
Adding sort[created] in 4 places in $:/plugins/ScottSauyet/WizardNav/ViewTemplate and reducing the font size a bit for mobile use seems to work.
Maybe the ‘created’ could be replaced with a variable that allows a different sort field to be set on the config page but the adjustment below works for me so far and I can see where to change the arrow icons/text too if I want. Thanks again Scott.
<$set name="currentNavStep" value={{!!title}}>
<table class="wizard-nav">
<$list filter="[is[current]tags[]tag{$:/plugins/ScottSauyet/WizardNav/config/TagName}sort[created]]">
<tr>
<td>
<$list filter="[enlist{!!list}] :else[tag{!!title}sort[created]] +[before<currentNavStep>]">
<$link to=<<currentTiddler>>>« <small>{{!!title}}</small></$link>
</$list>
</td>
<td>{{||$:/core/ui/TagTemplate}}</td>
<td>
<$list filter="[enlist{!!list}] :else[tag{!!title}sort[created]] +[after<currentNavStep>]">
<$link to=<<currentTiddler>>><small>{{!!title}}</small> »</$link>
</$list>
</td>
</tr>
</$list>
</table>
<$list filter="[[$:/plugins/ScottSauyet/WizardNav/config/AddLinksToTags]get[text]match[yes]]" variable="_">
<$list filter="[is[current]tag{$:/plugins/ScottSauyet/WizardNav/config/TagName}]">
<<list-links filter:"[all[current]tagging[]sort[created]]" type:"ol">>
</$list>
</$list>
</$set>
1 Like
Hi, you can use GitHub - tiddly-gittly/Tiddlywiki-WikiText-Plugin-Template: Simple plugin template, with Github Pages demo site. to get better dev experience, and will auto create .json plugin file in the github release, so it is easier to add plugin to the CPL, and easier for new user to install. (though I think this plugin is more like to be for experienced plugin authors?)
1 Like
Thank you. I will look at the issues this weekend and, I’m hoping, put out a new release.
Yes, that was what I was thinking for “created” - a tiddler that holds the name of the field, defaulting to “title”
I hadn’t even looked at mobile yet. My test case is not online except in a locked-down corporate network that won’t let you phone on it unless you surrender a lot of control over the phone. I don’t want GigantiCorp bricking my phone, thank you! I will check it out soon and see if the default font should change. (I don’t set it at all.)
Thanks. I will take a look. This is my first serious attempt at creating a plugin, and while it’s working reasonably well, there are three pain points. I’m wondering if this would fix them?
-
(minor) When I change the version, I need to keep it in sync between
package.jsonandplugin.info. I’m sure I could script this easily enough. -
(medium) I haven’t yet got a working GitHub Action, so I have to build, then push. I’d rather just push and have the build run on the GH side. This is not huge, but is a minor annoyance. I’m not particularly experienced with GH Actions, so while I was able to do this easily at work with Gitlab, my first two attempts here failed and I put it aside for the moment.
-
(major) Before I build, I need to manually move any changed plugin files from
/tiddlerstoplugins/myplugin. This is not difficult to do, and if I keep with this solution, I will find a way to automate it in my build. But it feels very wrong.
There is also one feature I really love in this workflow: I build not just the main demo but also a copy in a version-specific folder. So while this plugin is simply hosted on GH Pages, I also have older versions kept handy. I need to do nothing more to create this new version than update the version number in package.json (but see #1 above!) While this does not make GH releases, I don’t know whether I really care, as I expect the main distribution for a TW plugin to be an actual wiki, as in my demo.
Does this tool do something similar, that is, hosting older versions in demo pages?
I added the sort order configuration in 0.5.0.
…and I already have the idea for a better solution. Stat tuned.
Thanks @Scott_Sauyet it works!
I wasn’t sure at first but realised it’s an either/or between list field or custom sort field - e.g you need to delete the list field from the Tutorial tidd if you want to sort it on a custom field set in config.
Looking forward to seeing how you develop this plugin, it provides a nice way to step through tids on mobile.
Zoomin view with zero animation works for me but you end up with a lot of tiddlers open in the background so closing ‘current’ on click of ‘next’ or ‘previous’ could be another option for the future.
Thanks again Scott.
I don’t know how to do it. I’m sure I can find out, but if you have ideas how, please let me know. I wouldn’t make it the default, but it would make sense as something to opt into.
I think it might be doable - maybe saving the <currentNavStep> value to a ‘store tiddler’ and using that value with a tm-close-tiddler message on each ‘next’/‘previous’ button click? That would mean adding invisible buttons in there somewhere though. In the meantime it’s not so difficult closing the tidds manually so don’t knock yourself out Scott.
I’m pretty confident others will have much better suggestions. @Mohammad might have some prior examples.
1 Like
If you’re currently using links for “previous” and “next”, you’ll need to replace them with buttons (though you can still style them as links). You can then use tm-close-tiddler.
1 Like
This button in place of the template’s ‘previous/next’ links seems to work (you’ll need to change the chevron for next) but might need some testing with multiple pathways. I kept the ‘small’ for my mobile.
<$button class="tc-btn-invisible" message="tm-close-tiddler" param=<<currentNavStep>> to=<<currentTiddler>>>« <small>{{!!title}}</small></$button>
Looking at multiple pathways with a single custom sort field means the list field has to be deleted from both Wizard tagged tids (if that makes sense 
). Maybe that could be coded in somewhere?
The crossroads between those multiple pathways looks interesting, it’s a nice way to navigate on mobile.
1 Like
I’ve updated my previous “TOCNav” post (see Navigating complex tiddler relationships, a discussion for the enthusiast - #2 by EricShulman) so the toc-nav() macro (which displays the previous/next links) now includes a tm-close-tiddler message. As a result, the current tiddler is automatically closed when navigating to the previous/next tiddler.
I’ve also added a <<tag>> display into toc-nav(), so that if the current tiddler is a tag, the navigation includes a tag dropdown for all “child” tiddlers. This makes it easy to “drill down” directly to any given child tiddler as an alternative to the linear previous/next navigation.
Here’s the complete updated “TOCNav” code:
\define toc-nav()
<$list filter="[enlist<all>before<currentTiddler>]" variable="prev">
<$button class="tc-btn-invisible" style="float:left;" to=<<prev>>>
{{$:/core/images/chevron-left}} <$tiddler tiddler=<<prev>>><<toc-caption>></$tiddler>
<$action-sendmessage $message=tm-close-tiddler />
</$button>
</$list>
<$list filter="[enlist<all>after<currentTiddler>]" variable="next">
<$button class="tc-btn-invisible" style="float:right;" to=<<next>>>
<$tiddler tiddler=<<next>>><<toc-caption>></$tiddler> {{$:/core/images/chevron-right}}
<$action-sendmessage $message=tm-close-tiddler />
</$button>
</$list>
<$list filter="[<currentTiddler>is[tag]]">
<center><span style="text-align:left;"><<tag>></span></center>
</$list>
<div style="clear:both;"/>
\end
\define toc-list(here,max,exclude,level:"1")
<$list filter="""[tag[$here$]] $exclude$ -[[$here$]]""">
<$text text="[["/><<currentTiddler>><$text text="]]"/><br>
<$reveal default="$level$" type="nomatch" text="$max$">
<$macrocall $name="toc-list" here=<<currentTiddler>> max="$max$"
exclude="""$exclude$ -[[$here$]]""" level={{{ [[$level$]add[1]] }}}/>
</$reveal>
</$list>
\end
<$wikify name="all"
text="""<$macrocall $name="toc-list" here="TableOfContents" max=3/>""">
<<toc-nav>>
</$wikify>
2 Likes
Nice one @EricShulman
Scott’s approach wins for me though because of the ability to custom sort on the nav ‘steps’. I can click through the tagged set chronologically for example. His ‘multipath’ display on tag intersections looks interesting too, hope you get a chance to develop that Scott. Will stay tuned.
1 Like
Hi @EricShulman, just for beginners’s sake, the first define lacks an introductory slash. Thanks for correcting.
oops! That was a copy-paste glitch. Fixed. Thanks.
-e