In my Kansas Railroad wiki, I have what can be a long list of railroads that I have in a scrollable window. I was wondering if there was an easy way to be able to return to the last viewed scroll position next time I load the wiki. Googling the web, I see that there are javascript and jquery solutions, but I don’t know how to do that within Tiddlywiki. Has anyone thought about this before or am I treading new ground? Is this even reasonable? Thanks in advance!
This has being raised a number of times over the years, the first thing raised is if your wiki is structured into tiddlers, you can save the tiddler and have that reopened, but if you want to move to a position within a list, you need to define and capture the position, be it in a tiddler, and use a startup action OR using anchors on the url. It is possible to make use of links and anchors , but you will need to programmatically generate them.
Some smart developers may be able make a method to capture the scroll state of a list for use on reload.
If you designed the scroll system of a list to maintain a position you can use this on reload.
Another approach may be to capture what we may call the last focused railroad, then you would have a value to return to on reload. It may not remember the scroll position, but it could list the last focused railroad at the top.
There is a lot to this issue, so keep the conversation going until you can find an appropriate solution, but I recommend keeping an open mind to alternative approaches because some are a lot simpler than others to implement and maintain.
Unlike other websites, which move from one html page to another, tiddlywiki is one page with lots of internal navigation, that’s why using anchors, that exist in a pages “scope” are less straight forward than regular websites. If an anchor is not on the page you can’t jump to it.
Dynaview tracks elements with class="tc-dynaview-track-tiddler-when-visible" - despite the name, the elements don’t need to be tiddlers, though of course they could be.
Actually, now that I’m rereading the documentation, it looks like Dynaview may have this functionality right out of the box:
After looking at the Dynaview plugin and reading its documentation, it appears to me that the scroll position functionality only works on the story river.I would like it to work on a tab in the sidebar. Am I reading the documentation incorrectly?
I should have done this from the beginning. I’ve included a screenshot of my railroad wiki. On the right side, in the railroads tab of the sidebar, there is a div that lists the railroads that meet the criteria of the selectors above it. In this case, it is quite long. Being the lazy person that I am, I would like to not have to scroll to the position where I left off. Of course, I can always use my little navigator at the footer of the open tiddler to navigate through the list shown..
This is more of a curiousity question than it is a must have.
Thank you @pmario, I was just about to make a post about the experiment but you beat me to it. It’s just an idea, there may be a better way of doing it (I think it might be worth exploring a more generic mechanism for binding DOM node attributes to tiddler fields).
Thanks @jeremyruston and @pmario. This works pretty much exactly as I had visualized. It was also very easy to setup. I used $:/state/my-scroll-position to store the scroll position so that they dirty indicator wouldn’t turn red when I scrolled. I’ve only played with it a short time so not sure if there are any issues with it other than the scrolling is less responsive than without the scrollable widget. I’m assuming that this is because each time I scroll, it has to store the scroll position in the fields of the binding tiddler.
Edit: question - is there a way that the fields of the binding tiddler could only be written to upon a save of the wiki to increase the performance of the scrolling? I guess that would require some other temporary storage mechanism for the scroll position though.
That’s right. I plan to improve things by debouncing the updates so that they are not generated so frequently. As long as the update to the binding tiddler isn’t triggering an expensive refresh the performance should be reasonable once that’s done.