*Custom Target/tab: * I have now tested opening the current wiki in a new tab with the target set, so that if bookmarked, subsequent visits with the bookmark open the same named tab. I knew this worked however;
- At the very same time a link opens a new tab, the current tab can initiate a modal with no exit, requesting the user closes the tab. - If combined with the other interactions demanded by the "Chromium native file system saver plugin" the complexity is further reduced. - I re-tested the fact that bookmarks and/or pinned tabs (with a target set) retain knowledge of the target name used to open them Just to clarify my suggestions in this thread relate to using the " Chromium native file system saver plugin" to make a "wiki your own" with local saving - non-multiuser, it is multi-user in a sense each user ends up with their own wiki. I am also endeavoring to find solutions to make using this "saver" as simple to use as possible so it works for new users. See for more on requirements for multi-user my comments at https://talk.tiddlywiki.org/t/multi-user-alternative-to-tiddlywiki/2899/24?u=tw_tones On Saturday, 2 April 2022 at 15:43:33 UTC+11 TW Tones wrote: > On Saturday, 2 April 2022 at 05:55:53 UTC+11 dyllon...@gmail.com wrote: > >> >> - *Copy path to clipboard:* That's a good idea and should be possible >> when loaded as file://. UI design is a consideration here to make it >> clear >> to users when copying the path. >> >> It can be hidden within a custom/or customized save button once we are > confident the user is informed. > > >> >> - *Custom Target/tab: *Do you mean something like Open Links in a >> New Tab, Or Re-Use Already Existing Tab (usefulangle.com) >> <https://usefulangle.com/post/337/html-open-links-in-same-tab>? I >> think this only works when clicking on links from a common page. >> >> yes, as per your link, a vanilla browser target.The trick here is once > establishing that the user wants to revisit a site, and or have a local > copy that we use the target parameter when constructing a link to the > address we want in a named tab. Following that link once makes it a named > tab, and future links to the same target open the same tab. > Ideally we may be able to name the current tabs target (not sure we can), > worst case we open a new tab, closing the original tab. The key is to trap > it into A bookmark to open the site in future. > > <a href=" > https://tiddlywiki.com/#Saving%20on%20Browser%20with%20File%20System%20Access%20API"; > > target="tiddlywiki.com">Saving on Browser with File System Access API</a> > <a href="https://tiddlywiki.com/#HelloThere"; target="tiddlywiki.com > ">~HelloThere</a> > >> >> - *Local storage: *Not really all that safe since we can't guarantee >> that changes will be flushed to disk before leaving the browser >> >> From my own experiments this has never being a problem, and if the > changes are committed to disk with "Chromium native file system saver > plugin" this is a non-issue. All it does is defer the saving of changes to > a save wiki step, ie no need to auto-save. > >> >> - If going with that kind of approach, I would rather just use a JS >> lock which can work with tabs in the same browser window. >> >> I do not know what JS Lock is to compare. Can you enlighten me please. > > >> >> - *File Associations: *Might work, though that requires some platform >> specific code such as an installer to setup the associations. >> >> For windows this is a simple registry entry. A very simple install, done > once for all tiddlywikis. But the truth is we should build some installers > for each OS. > > For Timimi, there is obviously the solution of disabling the saver via a >> setting, but that obviously sucks if you have multiple people using the >> wiki. It'd be nice if there was a way to specify a priority for savers, but >> I don't think there is one right now. I don't want to add a bunch of custom >> logic to this saver for other specific savers. I could add in some special >> field containing JS that can be modified for determining whether to enable >> this saver or not, but that seems like a lot of complexity for users. >> > > I need to test this as the two may be possible at the same time, but it > could be a matter of manual disabling "Saving on Browser with File System > Access API" buy asking the user on first save, "*un-Check if you have > Timimi installed" as its not required. *Its all about finessing the > interface and options. > > - Is there a simple way to disable "Saving on Browser with File System > Access API" with a click?, or could you build one in? For Timimi, there is > obviously the solution of disabling the saver via a setting, but that > obviously sucks if you have multiple people using the wiki. It'd be nice > if > there was a way to specify a priority for savers, but I don't think there > is one right now. I don't want to add a bunch of custom logic to this > saver > for other specific savers. I could add in some special field containing JS > that can be modified for determining whether to enable this saver or not, > but that seems like a lot of complexity for users. > > I just had a thought, can we interfere with the reload button to open the > wiki in a "target tab"? Otherwise we just ask; > > - Please open the following link and bookmark the site, and pin the > tab (if desired) closing this existing tab. > - Perhaps also there is a possibility to make use of the "new Window" > open and close features of TW 5.2.2 > > Regards > Tones > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/ab08487e-3be7-4396-b0e8-f7bfc6dc63b7n%40googlegroups.com.
