Jeremy, is there an easy way to serialize the wiki to a string without
triggering a save? That would allow me to give a better integrity check if
people don't save immediately. I can't just "await
fetch("./example-wiki.html")" because of dumb browser restrictions with
file://. That was what I initially tried to do.
Thanks,
Dyllon
On Sunday, February 20, 2022 at 3:32:50 AM UTC-8 [email protected] 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 <[email protected]> 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 [email protected]
>>>> 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 [email protected]
>>>>>> 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
>>> [email protected].
>>> 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 [email protected].
>> 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 [email protected].
>
> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/f5e7d994-1f2e-47ed-8ee5-bf8ba6de7db0n%40googlegroups.com.
