Aside: CJ, being my other handle. For reference, if of use, my recent posts related to TiddlyWiki and local storage:
- Local storage prototype: TiddlyWiki and BASIC data exchange <https://groups.google.com/g/tiddlywiki/c/ALUN9aSDBuw> - Using one TiddlyWiki as a "server" of content to another "client" TiddlyWiki <https://groups.google.com/g/tiddlywiki/c/aOzaAsFv38k> - TW-Enhanced BAM Programming: TW for GUI and storage, BASIC for processing <https://groups.google.com/g/tiddlywiki/c/P0hfGQeRYwo> On Sunday, February 20, 2022 at 3:21:41 PM UTC-4 hww...@gmail.com wrote: > I think this approach might work within the Local Storage solution that CJ > has developed. Unfortunately I am supporting a couple of "life and health" > issues just now, so I am not able to test that assumption personally.. > > Hans > > > On Sunday, February 20, 2022 at 6:32:50 AM UTC-5 Jeremy Ruston wrote: > >> Hi Brian, >> >> I seem to recall https://tiddlywiki.fission.app/ implements such a >> launcher, >> >> >> That’s right. TiddlyDesktop also has a similar architecture. The >> challenge with Fission is that images stored in ones Fission drive are not >> accessible via a URL; there’s just a JS API to retrieve specific files. I >> have experimented with using a service worker to map local URLs to the JS >> API, which I think might be a promising generic technique for working with >> non-URL-based storage. >> >> but currently that page has an endlessly spinning "Authorizing with >> fission" message and the console has an "Uncaught (in promise) Error: >> Improperly formatted header value: skeleton" in webnative.js, so I couldn't >> confirm my memory. >> >> >> I hope to be able to work on TiddlyWiki on Fission soon, and will make an >> update to the latest version of the SDK. >> >> Best wishes >> >> Jeremy >> >> I think the workflow implemented by the above two apps is "safer" than >> what I saw in the TW chromium native file saver. With the TW native saver >> the workflow looks like this: >> >> 1. Load my native saver enabled TW using some url (possibly a file:// >> url) >> 2. Click the Save button in HTML Native File System Saver modal >> 3. From the file dialog select the same file I'm already editing >> 4. Dialog box "a file with this name already exists, do you want to >> replace it?" >> 5. Start sweating a little bit...if I've chosen the wrong file here, >> I might be overwriting something important >> 6. Sweat a little bit more especially if I've loaded it from a web >> url where it isn't as easy to tell that I've selected the matching file >> or >> not >> 7. Cross my fingers, click the "replace" button and hope for the best >> >> The bangle and diagrams.net applications don't have the same room for >> user error since you are prompted for what file to read and then it >> automatically saves back to that same file. I find that workflow to be less >> nerve-wracking. >> >> Maybe with tiddlywiki's unique structure there is an even better workflow >> to be had, I don't know. And maybe the TW nativesaver can already be used >> with a better workflow and I just missed it. >> >> >>> On Fri, 18 Feb 2022 at 20:13, TW Tones <anthony...@gmail.com> wrote: >>> >>>> Folks, >>>> >>>> I believe this is already available on tiddlywiki.com at >>>> https://tiddlywiki.com/#Saving%20on%20Browser%20with%20File%20System%20Access%20API >>>> >>>> It is not yet comprehensively documented and it is hard for me to >>>> determine what level of functionality and customisation is available to >>>> us. >>>> As a solution only on Chromium browsers it is not yet global in >>>> application, so understanding its value is even harder to determine. >>>> >>>> I also ask myself "We require a click event to start the save dialogue" >>>> if this could not be placed in a save button "lookalike" or another way to >>>> make it user friendly. Ie just in time, not startup, Although in this >>>> thread others suggest they do not need it. >>>> >>>> Can someone write a user designer perspective and/or comparison with >>>> existing methods? >>>> >>>> My concerns; >>>> >>>> - How to design online tiddlywikis with a non-intrusive saving >>>> mechanism users can understand. >>>> - Dealing with the contention possible with two parties editing the >>>> same site. >>>> >>>> I would appreciate it is someone can spell this out a little more for >>>> us who need it, and can't easily understand this from the jargon and >>>> reading between the lines in this discussion. >>>> >>>> Thanks >>>> Tones >>>> On Wednesday, 9 February 2022 at 11:10:40 UTC+11 PMario wrote: >>>> >>>>> Hi, >>>>> I do like that option. >>>>> -mario >>>>> >>>>> On Wednesday, February 9, 2022 at 12:11:06 AM UTC+1 >>>>> dyllon...@gmail.com wrote: >>>>> >>>>>> It does work, though I think it is disruptive asking as soon as >>>>>> something is done which triggers autosave. However, I have put in an >>>>>> option >>>>>> with version 0.7.1 to disable the modal for those who don't like it. >>>>>> >>>>>> On Sunday, February 6, 2022 at 1:46:16 AM UTC-8 PMario wrote: >>>>>> >>>>>>> On Sunday, February 6, 2022 at 12:54:25 AM UTC+1 brian....@gmail.com >>>>>>> wrote: >>>>>>> ... >>>>>>> >>>>>>>> Now with the indexdb entry re-populated, the sequence looks like >>>>>>>> this: >>>>>>>> >>>>>>>> 1. Reload the TW page >>>>>>>> 2. Click the + button to create a new tiddler >>>>>>>> 3. Click the checkmark to save the tiddler >>>>>>>> 4. A dialog box asks me if I want to let the site edit the >>>>>>>> file. I click the "edit file" button >>>>>>>> 5. The file saves >>>>>>>> >>>>>>>> So it is working for me even without the settings modal. Do you see >>>>>>>> this same behavior? >>>>>>>> >>>>>>> >>>>>>> I also think the modal isn't needed. The API requires user >>>>>>> interaction. ... But I think the described behaviour is good. The >>>>>>> permission is requested, when the first save happens. Since this save >>>>>>> is a >>>>>>> user interaction it should be good enough. >>>>>>> >>>>>>> -mario >>>>>>> >>>>>> >>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "TiddlyWiki" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/tiddlywiki/ihoCXMIkz9I/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> tiddlywiki+...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/tiddlywiki/6ee85fa3-f495-4a11-874d-01aa02db7a52n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/tiddlywiki/6ee85fa3-f495-4a11-874d-01aa02db7a52n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >>> -- >>> 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 view this discussion on the web visit >>> https://groups.google.com/d/msgid/tiddlywiki/CAAY2DnOq8LXuyC_4YJR6Q7KTU7%2Bek%3Ds_ZhGbYG_qa4PMEpir1A%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/tiddlywiki/CAAY2DnOq8LXuyC_4YJR6Q7KTU7%2Bek%3Ds_ZhGbYG_qa4PMEpir1A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> -- >> 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 view this discussion on the web visit >> https://groups.google.com/d/msgid/tiddlywiki/CAO5X8CzqmcQes5UTs%3DUDh_KDkSqp18_fpZc_ekvGF-iMeQ3SYQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/tiddlywiki/CAO5X8CzqmcQes5UTs%3DUDh_KDkSqp18_fpZc_ekvGF-iMeQ3SYQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> >> -- 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/c33dfae7-b300-4f6e-940d-a7fef53e9cfbn%40googlegroups.com.