Dylon,
*One of the reasons for introducing the save button at startup is so the
plugin can quickly read the original file and compute its file hash as soon
as possible.*
In some of my own experiments, in a startup action if the wiki is available
for editing I immediately save and reload it to indicate this session "owns
it". Similarly when finished the final save needs to release it.
- With a splash screen advising its loading this may be ok because in
need only be done once per session (that has the wiki for edit/save) even
on larger wikis.
I have come across two issues;
- The browser session needs a finger print to be saved in local storage,
so this can be compared with the loaded copy of the wiki to check ownership
- I have found an almost unique fingerprint
- If the wiki is on file:// I have not found how to get a seperate
finger print for each tab, so it could be opened in more than one tab and
save will only save the current tabs changes.
Have you found a way to open a file:// wiki in two tabs and not confuse the
session?
On Wednesday, 23 February 2022 at 13:09:32 UTC+11 [email protected] wrote:
> For contention, the current version actually does provide some integrity
> measures. One of the reasons for introducing the save button at startup is
> so the plugin can quickly read the original file and compute its file hash
> as soon as possible.
>
> One the first save (i.e. when you click the button on the launch modal),
> the hash of the serialized wiki is recorded. On subsequent saves, the
> plugin compares the hash of the new version to the hash of the old version
> to see if the file has changed unexpectedly (i.e. changes were made in a
> different browser pane or it is on a network drive and someone else changed
> it).
>
> I'm hesitant to rely too much on Tiddlywiki internals to try and maintain
> forward compatibility, but it would be nice if this check were possible
> without triggering an actual save. The other reason is to avoid unexpected
> prompts when autosaving things obviously.
>
> I will also admit that as a software developer, I'm not the best person at
> making people understand the saving mechanism without overwhelming them
> with technical details.
>
> As for using a more intuitive save button, I'm welcome to suggestions
> and/or pull requests so long as things scale for different browser/wiki
> layouts and it doesn't pull in any large images (an SVG or something would
> probably be ok). I agree the button used right now is kind of ugly. Another
> thing to keep in mind with suggestions is that people might be using
> different color schemes which I'd like the plugin to try and respect.
>
> Thanks for your feedback!
>
> On Friday, February 18, 2022 at 5:13:26 PM UTC-8 TW Tones 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 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/b3a7b412-269d-4ddd-bd51-430e20c47994n%40googlegroups.com.
