Re: [tw5] Major updates to Chromium native file system saver plugin

[PMario]

On Friday, April 1, 2022 at 8:55:53 PM UTC+2 dyllon...@gmail.com wrote:

> ...

 

> 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. 
>

Saver modules do export a name and a priority. I think the lower the lowest 
priority-number wins. ... But I'm not sure. 
A saver also exports a .canSave() function, which is used by the 
saver-handler to see if a saver can be used. .. The first saver that 
returns .canSave() === true sorted by priority will be used to save. 

IMO the canSave() function can be used to dynamically enable/disable a 
saver. 

See: 
https://github.com/Jermolene/TiddlyWiki5/tree/master/core/modules/savers


-- 
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/fd0ff6d3-fb62-4ef4-b3f7-a487d0d14613n%40googlegroups.com.

Re: [tw5] Major updates to Chromium native file system saver plugin

[TW Tones]

 *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) 
>>? 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.
>  
> https://tiddlywiki.com/#Saving%20on%20Browser%20with%20File%20System%20Access%20API;
>  
> target="tiddlywiki.com">Saving on Browser with File System Access API
> https://tiddlywiki.com/#HelloThere; target="tiddlywiki.com
> ">~HelloThere
>
>>
>>- *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 

Re: [tw5] Major updates to Chromium native file system saver plugin

[TW Tones]

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) 
>? 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.
 
https://tiddlywiki.com/#Saving%20on%20Browser%20with%20File%20System%20Access%20API;
 
target="tiddlywiki.com">Saving on Browser with File System Access API
https://tiddlywiki.com/#HelloThere; 
target="tiddlywiki.com">~HelloThere

>
>- *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/0dd5f90e-2d8a-4d05-8a9c-bcb9e4fe0067n%40googlegroups.com.

Re: [tw5] Major updates to Chromium native file system saver plugin

[Dyllon Gagnier]

   
   - *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.
   - *Custom Target/tab: *Do you mean something like  Open Links in a New 
   Tab, Or Re-Use Already Existing Tab (usefulangle.com) 
   ? I think 
   this only works when clicking on links from a common page.
   - *Local storage: *Not really all that safe since we can't guarantee 
   that changes will be flushed to disk before the browser closes. 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.
   - *File Associations: *Might work, though that requires some platform 
   specific code such as an installer to setup the associations.
   
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.

On Thursday, March 24, 2022 at 8:04:16 PM UTC-7 TW Tones wrote:

> Folks,
>
> I am watching this with "bated breath" ( *in a nervous and excited state 
> anticipating what will happen*) however as I do not understand the 
> technical part of the saver I am finding it hard to contribute.
>
> It seems to me this is approaching the "Nirvana" of savable wikis without 
> any additional installation of servers, savers or Browser addons. This will 
> transform how people can acquire, use and distribute wikis to naive users. 
> It just needs a little more work. 
>
> What follows is some 'innovative' solutions I have developed that may be 
> able to smooth the path to a solution with the least "resistance" of not 
> almost transparent.
>
>- You may also find these tips and tricks powerful in their own right.
>- 'Innovative because' "I see few if anyone using them" 
>
>
> I believe I can add a lot here but there remains a slight technical 
> barrier for me. What I want to see is to minimize user interaction 
> including between reloads, and when forced interaction is necessary, 
> improve and guide the user for minimum complexity. Here are a few 
> techniques that may help overcome the barriers.
>
>- *Copy path to clipboard*: If we want to save a tiddlywiki to an 
>existing location, as may be forced when reloading the wiki or browser, we 
>already have the full path and filename available in the browser, it just 
>needs to be available to the save as dialogue. 
>- I have created a save button with additional actions that copies the 
>   contents of $:/info/url/full to the clipboard, where ctrl-V pastes 
>   the full path and filename and I just click save.
>   - This would save the need to remember the full path and filename 
>   and reduce the error of selecting the wrong file
>   - Remember also
>  - the full path tells you if the wiki is at a file location 
>  which is a useful piece of information
>  - If we have a modal pop up as mentioned below in "Bait and 
>  switch", this can be explained for the user, perhaps a variation for 
> the 
>  detected OS.
>  - *Custom Target/tab:* If we want to protect against opening the 
>same wiki in a tab, one trick is after the first save (knowing the full 
>path and filename) we can construct a html link with an appropriate target 
>attribute, then navigate to that (if possible closing the original tab), 
>thus the wiki is now running in a tab with a named target. 
>- If we bookmark or pin the tab this remains the target. If clicked in 
>   future it will open the very same tab, never another new tab.
>  - Warns if unsaved changes exist in the tab.
>  - This should help given the global file:// issues 
>   - *Bookmarklet*: Perhaps extending the value of Custom Target/tab 
>and because there is value using it, we can consider the use of a 
>bookmarklet both with a target and a payload if necessary. An example may 
>be so if the user returned to the source site, published on the internet 
>the bookmarklette can recall you already have a local copy and with a 
>click. When saving from the source URL for the first time we could prompt 
>the user to use their saved bookmark if they want to access their local 
>copy, to not create a new one, or override and existing one.
>- *Bait and switch: *Using the existing save button or a customized 
>copy which does more work than the default save button, on this occasion 
>opening a 

Re: [tw5] Major updates to Chromium native file system saver plugin

[Dyllon Gagnier]

Yes, though assuming you use this plugin in another writer, it should be 
detected on the other side. The only way to really run into problems is 
with very rapid race conditions. Something like:


   1. Window 1: Initiate a save, confirm the original value to be X.
   2. Window 1 stops executing due to OS/browser scheduler.
   3. Window 2: Initiate save, confirm original value to be X.
   4. Window 1: Finishes write Y.
   5. Window 2: Finishes write Z.

While unlikely, this could happen and any changes in Y would be overwritten 
with Z.

I did some investigation, and it looks like it is possible to serialize the 
wiki for comparison before the first save. I'm investigating that, but 
there are some weird scenarios where the first save is slightly different 
from subsequent saves.
On Wednesday, February 23, 2022 at 4:38:49 PM UTC-8 brian@gmail.com 
wrote:

> Dyllon,
>
> On Tue, Feb 22, 2022 at 9:32 PM Dyllon Gagnier  
> wrote:
> [...]
>
>> In terms of stressing if you picked the right file, assuming you used the 
>> modal button, you don't need to stress out too much since the consistency 
>> check should catch that.
>>
>
> The stress I describe in steps 1-7 below is only about using the modal 
> button. During the first save, the consistency check is not done, right? 
> Therefore, that first save during each session is a potentially damaging 
> operation. That's the source of the stress.
>
>  
>
>> On Saturday, February 19, 2022 at 5:45:06 AM UTC-8 brian@gmail.com 
>> wrote:
>>
>>> On Fri, Feb 18, 2022 at 8:16 PM Frédéric Demers  
>>> wrote:
>>>
 As inspiration, this seems to be a decent implementation of native file 
 storage API: https://bangle.io

>>>
>>> This does look pretty good. Another example is https://app.diagrams.net/
>>> .
>>>
>>> These two apps have a webpage at a well-known url which holds the 
>>> javascript functionality. The data files are loaded in separately. Compare 
>>> this to tiddlywiki in which the functionality and the data is combined 
>>> together into a single file.
>>>
>>> I think to implement the same workflow in tiddlywiki, you'd have to have 
>>> a "launcher" instance of tiddlywiki which would read a tiddlywiki instance 
>>> from disk as the "data file".
>>>
>>> I seem to recall https://tiddlywiki.fission.app/ implements such a 
>>> launcher, 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 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.
>>>
>> [...] 
>

-- 
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/89243ba6-2606-4133-a23d-324433af17c4n%40googlegroups.com.

Re: [tw5] Major updates to Chromium native file system saver plugin

[TW Tones]

Brian;


>>- *Copy path to clipboard*: If we want to save a tiddlywiki to an 
>>existing location, as may be forced when reloading the wiki or browser, 
>> we 
>>already have the full path and filename available in the browser, it just 
>>needs to be available to the save as dialogue.
>>
>> Does this one have any technical barrier for you? Sounds like you have it 
> figured out. Sounds like a useful approach as long as the tiddlywiki is 
> loaded from a file url.
>

The only issue is the user needs to be told and/or reminded they can use 
crtl-v in the file dialogue. Its a trick and not commonly used, although 
easy to use. This is why if we can rely on local storage for small changes 
(no auto-save) and trigger a modal when saving we can present a modal to 
guide the user and address the need for the button click.

 

> [...]
>
>>
>>- *Custom Target/tab:* If we want to protect against opening the same 
>>wiki in a tab, one trick is after the first save (knowing the full path 
>> and 
>>filename) we can construct a html link with an appropriate target 
>>attribute, then navigate to that (if possible closing the original tab), 
>>thus the wiki is now running in a tab with a named target.
>>
>> What needs to know the full path and filename here? The user will know 
> and the browser will know, but the functionality running in the web page 
> (i.e. the tiddlywiki instance) will not know. It only has access to the 
> filename minus the directory location. The directory location is hidden 
> from it.
>

The full path and directory is known by a tiddlywiki loaded from file. If a 
user stores the full path and filename in a wiki it also known to that wiki 
(eg store in a cookie)

>
> The user has the information required to construct the html link you 
> mention, but the tiddlywiki page does not.
> [...]
>
 
Unless it is given and stores the full path and filename, however if we 
have a bookmarklet it can store the the full path and filename including a 
target tab. Clicking the same bookmark will always open in the same tab 
avoiding the opening of multiple tabs and the  global file:// issues(see 
next notes)

>
>>- 
>>   - This should help given the global file:// issues
>>   
>> I'm not sure what you mean here.
>

Just the "problem" with all file tiddlywikis having access to the same 
file:// domain. However it could be used for communication between wikis if 
we wanted. However as a rule we want a file:// tiddly wiki opened only once 
in a browser (or any browser) so there is not "contention"
 

>
>>- *Bookmarklet*: Perhaps extending the value of Custom Target/tab and 
>>because there is value using it, we can consider the use of a bookmarklet 
>>both with a target and a payload if necessary. 
>>
>> What do you mean by "payload"? Could you give an example? 
>
>>
>>- An example may be so if the user returned to the source site, 
>>published on the internet the bookmarklette can recall you already have a 
>>local copy and with a click. When saving from the source URL for the 
>> first 
>>time we could prompt the user to use their saved bookmark if they want to 
>>access their local copy, to not create a new one, or override and 
>> existing 
>>one.
>>
>> I'm not sure how the bookmarklet would know you already have a local copy 
>

The bookmarklet only exists if you created it from a local copy, it 
contains the link and target but can include a payload ie a tiddler 
containing details about the local copy. Thus the bookmarklete knows you 
have a local copy.

A trick that can be used is on arriving at an internet site we want to save 
a local copy we use the existing mechanism to save the local copy, then we 
can open that copy (ideally closing the internet tab #1). Once you have 
opened the local copy, you have access to the full path. Now so we do not 
loose the link to the local copy we can provide a link (we build it and can 
add a payload) for users to drag into their favorites and bookmarks.

#1 - before closing the internet tab

   - Save a cookie (or more) for that site indicating the existence of a 
   local copy.
   - When our internet wiki loads it can test for these cookies, and advise 
   the user a local copy exists. 
   - It can then ask ONCE the bookmark to be clicked, dropping the "payload 
  tiddler", then the internet site can also save the full path into the 
  cookie(s)
   - Subsequent visits to the internet site in the same browser can list 
   all local copies of itself and provide links to its target tab OR allow new 
   copies to be saved locally.

I know my replies are somewhat convoluted but this is a somewhat complex 
problem with substantial features if we can achieve it. I believe we just 
need a little more tweaking and a strong guided workflow.

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop 

Re: [tw5] Major updates to Chromium native file system saver plugin

[Brian Theado]

On Thu, Mar 24, 2022 at 11:04 PM TW Tones  wrote:
[...]

> I believe I can add a lot here but there remains a slight technical
> barrier for me.
>


> What I want to see is to minimize user interaction including between
> reloads, and when forced interaction is necessary, improve and guide the
> user for minimum complexity. Here are a few techniques that may help
> overcome the barriers.
>
>- *Copy path to clipboard*: If we want to save a tiddlywiki to an
>existing location, as may be forced when reloading the wiki or browser, we
>already have the full path and filename available in the browser, it just
>needs to be available to the save as dialogue.
>
> Does this one have any technical barrier for you? Sounds like you have it
figured out. Sounds like a useful approach as long as the tiddlywiki is
loaded from a file url.
[...]

>
>- *Custom Target/tab:* If we want to protect against opening the same
>wiki in a tab, one trick is after the first save (knowing the full path and
>filename) we can construct a html link with an appropriate target
>attribute, then navigate to that (if possible closing the original tab),
>thus the wiki is now running in a tab with a named target.
>
> What needs to know the full path and filename here? The user will know and
the browser will know, but the functionality running in the web page (i.e.
the tiddlywiki instance) will not know. It only has access to the filename
minus the directory location. The directory location is hidden from it.

The user has the information required to construct the html link you
mention, but the tiddlywiki page does not.
[...]

>
>-
>   - This should help given the global file:// issues
>
> I'm not sure what you mean here.

>
>- *Bookmarklet*: Perhaps extending the value of Custom Target/tab and
>because there is value using it, we can consider the use of a bookmarklet
>both with a target and a payload if necessary.
>
> What do you mean by "payload"? Could you give an example?

>
>- An example may be so if the user returned to the source site,
>published on the internet the bookmarklette can recall you already have a
>local copy and with a click. When saving from the source URL for the first
>time we could prompt the user to use their saved bookmark if they want to
>access their local copy, to not create a new one, or override and existing
>one.
>
> I'm not sure how the bookmarklet would know you already have a local copy
[...]

-- 
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/CAO5X8CzTsJzpJBRtmjR9oh8p1kTHTsXSD1nWd%3Dd%2BMbPGZcOgng%40mail.gmail.com.

Re: [tw5] Major updates to Chromium native file system saver plugin

[TW Tones]

Folks,

I am watching this with "bated breath" ( *in a nervous and excited state 
anticipating what will happen*) however as I do not understand the 
technical part of the saver I am finding it hard to contribute.

It seems to me this is approaching the "Nirvana" of savable wikis without 
any additional installation of servers, savers or Browser addons. This will 
transform how people can acquire, use and distribute wikis to naive users. 
It just needs a little more work. 

What follows is some 'innovative' solutions I have developed that may be 
able to smooth the path to a solution with the least "resistance" of not 
almost transparent.

   - You may also find these tips and tricks powerful in their own right.
   - 'Innovative because' "I see few if anyone using them" 


I believe I can add a lot here but there remains a slight technical barrier 
for me. What I want to see is to minimize user interaction including 
between reloads, and when forced interaction is necessary, improve and 
guide the user for minimum complexity. Here are a few techniques that may 
help overcome the barriers.

   - *Copy path to clipboard*: If we want to save a tiddlywiki to an 
   existing location, as may be forced when reloading the wiki or browser, we 
   already have the full path and filename available in the browser, it just 
   needs to be available to the save as dialogue. 
   - I have created a save button with additional actions that copies the 
  contents of $:/info/url/full to the clipboard, where ctrl-V pastes 
  the full path and filename and I just click save.
  - This would save the need to remember the full path and filename and 
  reduce the error of selecting the wrong file
  - Remember also
 - the full path tells you if the wiki is at a file location which 
 is a useful piece of information
 - If we have a modal pop up as mentioned below in "Bait and 
 switch", this can be explained for the user, perhaps a variation for 
the 
 detected OS.
 - *Custom Target/tab:* If we want to protect against opening the 
   same wiki in a tab, one trick is after the first save (knowing the full 
   path and filename) we can construct a html link with an appropriate target 
   attribute, then navigate to that (if possible closing the original tab), 
   thus the wiki is now running in a tab with a named target. 
   - If we bookmark or pin the tab this remains the target. If clicked in 
  future it will open the very same tab, never another new tab.
 - Warns if unsaved changes exist in the tab.
 - This should help given the global file:// issues 
  - *Bookmarklet*: Perhaps extending the value of Custom Target/tab and 
   because there is value using it, we can consider the use of a bookmarklet 
   both with a target and a payload if necessary. An example may be so if the 
   user returned to the source site, published on the internet the 
   bookmarklette can recall you already have a local copy and with a click. 
   When saving from the source URL for the first time we could prompt the user 
   to use their saved bookmark if they want to access their local copy, to not 
   create a new one, or override and existing one.
   - *Bait and switch: *Using the existing save button or a customized copy 
   which does more work than the default save button, on this occasion opening 
   a modal with an explanation rather than adding another tiddler and set of 
   instructions would be wise. One could also allow the full path top be 
   copied to the clipbord etc... 
   - However this modal would not be displayed if it can go ahead and save 
  automatically. 
  - *Local storage:* As long as one does not tax the local storage 
   much, it can act as a fairly safe space to store changes, and if when 
   closing the tab the dirty indicator triggered the Native file save, then 
   all tiddlers are saved to file and the local storage vacated. 
   - The point here is automated save is not necessary but can be optional. 
  The user should be able to choose when they invoke the file saving.
   - *File Associations: *Most browsers on opening a tiddlywiki file, what 
   ever its name, detect its html and opens it as expected. This allows us to 
   save tiddlywikis as for example a empty.tw file. Helping distinguish it 
   from all other html files. Then we can provide (yes install) a file 
   association to force such files to be opened in a particular browser, in 
   this case the one with local storage for that wiki such as the one 
   containing the IndexDB. Perhaps a .twc (tiddlywiki chrome) or .twf firefox 
   or .twe tiddlywiki edge would be useful.
  - Browsers also enable handlers for given extension/mime types to be 
  set, which may be another avenue to improve user interaction more eg .tw*
  - *Note:* For me, if my default browser, or all browsers have the 
   Timimi extension installed it does not matter in which 

Re: [tw5] Major updates to Chromium native file system saver plugin

[Brian Theado]

Dyllon,

On Tue, Feb 22, 2022 at 9:32 PM Dyllon Gagnier 
wrote:
[...]

> In terms of stressing if you picked the right file, assuming you used the
> modal button, you don't need to stress out too much since the consistency
> check should catch that.
>

The stress I describe in steps 1-7 below is only about using the modal
button. During the first save, the consistency check is not done, right?
Therefore, that first save during each session is a potentially damaging
operation. That's the source of the stress.



> On Saturday, February 19, 2022 at 5:45:06 AM UTC-8 brian@gmail.com
> wrote:
>
>> On Fri, Feb 18, 2022 at 8:16 PM Frédéric Demers 
>> wrote:
>>
>>> As inspiration, this seems to be a decent implementation of native file
>>> storage API: https://bangle.io
>>>
>>
>> This does look pretty good. Another example is https://app.diagrams.net/.
>>
>> These two apps have a webpage at a well-known url which holds the
>> javascript functionality. The data files are loaded in separately. Compare
>> this to tiddlywiki in which the functionality and the data is combined
>> together into a single file.
>>
>> I think to implement the same workflow in tiddlywiki, you'd have to have
>> a "launcher" instance of tiddlywiki which would read a tiddlywiki instance
>> from disk as the "data file".
>>
>> I seem to recall https://tiddlywiki.fission.app/ implements such a
>> launcher, 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 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.
>>
> [...]

-- 
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/CAO5X8Czfvk0qoQxc-j%2BE9yPi7OV7Pz18sX18r-KCqV4Lk8quzQ%40mail.gmail.com.

Re: [tw5] Major updates to Chromium native file system saver plugin

[Dyllon Gagnier]

It's not really a locking system like you describe. Instead, it basically 
works by comparing the contents of the data that was saved last time to 
what it reads off of the disk. If it doesn't match what it expects, an 
error is reported. It uses hashing to make this take less memory, but that 
doesn't make that much of a difference besides reducing memory consumption.

My suggested route for recovery if an error is reported there is to attempt 
to save again. It will fall back to the download saver and you will have to 
merge the two versions manually using tiddler import/export.

I've uploaded a YouTube video demonstrating how the check works. Note that 
since the plugin only cares about contents, the wiki needs to be 
non-identical (usually happens immediately due to modification timestamps).

https://youtu.be/F6HZo1e-5k8

It would definitely be possible to store a session fingerprint in local 
storage or IndexedDB to check for issues locally. However, that doesn't 
prevent issues with concurrent modifications from different browsers or on 
different computers via network drives.
On Tuesday, February 22, 2022 at 7:47:20 PM UTC-8 TW Tones wrote:

> 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 dyllon...@gmail.com 
> 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 

Re: [tw5] Major updates to Chromium native file system saver plugin

[TW Tones]

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 dyllon...@gmail.com 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 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 

Re: [tw5] Major updates to Chromium native file system saver plugin

[Dyllon Gagnier]

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 jeremy...@gmail.com 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  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
>>>

Re: [tw5] Major updates to Chromium native file system saver plugin

[Dyllon Gagnier]

I actually implemented something similar in an experimental branch to the 
launcher idea a while back but abandoned it because it felt very clunky to 
me  slaymaker1907/TW5-browser-nativesaver at sync-adaptor (github.com) 

.

The biggest problem was that sync adaptors don't work as nicely as regular 
savers with falling back to another saver in case of errors. If people were 
interested in that approach, it would probably be better done as a separate 
plugin and just duplicate code since savers work very differently compared 
to sync modules. It's also a lot more work since there is much less 
documentation on sync adaptors compared to vanilla saver modules.

One thing I still like about the sync adaptor/folder wiki idea is that 
versioning can be done much more cheaply (at the cost of recovery 
complexity if you want to go back to an old version). Instead of just 
saving the whole wiki each time, the plugin could just save the old version 
of the changed tiddlers.

If the API supported it, I'd love to just save the old versions in a 
compressed file so it takes up less space. However, that isn't really 
practical since JSZip is a huge dependency for one plugin and because the 
file system API can't do changes in place. You have to completely write the 
whole file each time.

Thinking about that issue though, I could possibly implement gzip 
compression for the individual versioned files. Plain gzip at level 5 gives 
a compression ratio of ~17% for the example wiki (so compressed it is 17% 
the size of the original) which is quite a bit. I don't want to do some 
sort of diff or patch algorithm since I don't know if I trust myself enough 
to implement such a thing correctly plus you can't just use 7zip in that 
case to recover the data. isomorphic-git · A pure JavaScript implementation 
of git for node and browsers!  might also 
work so it's just a git repo in that case.

In terms of stressing if you picked the right file, assuming you used the 
modal button, you don't need to stress out too much since the consistency 
check should catch that.
On Saturday, February 19, 2022 at 5:45:06 AM UTC-8 brian@gmail.com 
wrote:

> On Fri, Feb 18, 2022 at 8:16 PM Frédéric Demers  
> wrote:
>
>> As inspiration, this seems to be a decent implementation of native file 
>> storage API: https://bangle.io
>>
>
> This does look pretty good. Another example is https://app.diagrams.net/.
>
> These two apps have a webpage at a well-known url which holds the 
> javascript functionality. The data files are loaded in separately. Compare 
> this to tiddlywiki in which the functionality and the data is combined 
> together into a single file.
>
> I think to implement the same workflow in tiddlywiki, you'd have to have a 
> "launcher" instance of tiddlywiki which would read a tiddlywiki instance 
> from disk as the "data file".
>
> I seem to recall https://tiddlywiki.fission.app/ implements such a 
> launcher, 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 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  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 

Re: [tw5] Major updates to Chromium native file system saver plugin

[Dyllon Gagnier]

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 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 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/934341cb-bca7-444c-991d-a02fed018d9en%40googlegroups.com.

Re: [tw5] Major updates to Chromium native file system saver plugin

[Hans Wobbe]

Thanks for the additional email.

As much as I would like to dig into this, as I said, I am over-whelmingly
pre-occupied.

FYI, (in spite of it being a Privacy breach) Lisa is still in the ICU as a
result of “complications”.
Not only is her well-being important in itself, she also plays an important
role in managing some of our project work-flows.  We will be a while
sorting this out, I think.

Back to your environments, I think we should take a look at how the
automated sharing among the NodeJs based instances of TW that you set up,
might interact through your local storage environment.

I’ll try to get some more resources to wirk with you shortly.


Hans




On Sun, Feb 20, 2022 at 15:23 Charlie Veniot  wrote:

> 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
>
>- Using one TiddlyWiki as a "server" of content to another "client"
>TiddlyWiki 
>- TW-Enhanced BAM Programming: TW for GUI and storage, BASIC for
>processing 
>
> 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  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 

Re: [tw5] Major updates to Chromium native file system saver plugin

[Charlie Veniot]

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 
   
   - Using one TiddlyWiki as a "server" of content to another "client" 
   TiddlyWiki 
   - TW-Enhanced BAM Programming: TW for GUI and storage, BASIC for 
   processing 
   
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  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 

Re: [tw5] Major updates to Chromium native file system saver plugin

[Hans Wobbe]

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  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 
>>> 

Re: [tw5] Major updates to Chromium native file system saver plugin

[Jeremy Ruston]

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:
> Load my native saver enabled TW using some url (possibly a file:// url)
> Click the Save button in HTML Native File System Saver modal
> From the file dialog select the same file I'm already editing
> Dialog box "a file with this name already exists, do you want to replace it?"
> Start sweating a little bit...if I've chosen the wrong file here, I might be 
> overwriting something important
> 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
> 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  > 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:
> Reload the TW page
> Click the + button to create a new tiddler
> Click the checkmark to save the tiddler
> A dialog box asks me if I want to let the site edit the file. I click the 
> "edit file" button
> 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 
> 

Re: [tw5] Major updates to Chromium native file system saver plugin

[Brian Theado]

On Fri, Feb 18, 2022 at 8:16 PM Frédéric Demers 
wrote:

> As inspiration, this seems to be a decent implementation of native file
> storage API: https://bangle.io
>

This does look pretty good. Another example is https://app.diagrams.net/.

These two apps have a webpage at a well-known url which holds the
javascript functionality. The data files are loaded in separately. Compare
this to tiddlywiki in which the functionality and the data is combined
together into a single file.

I think to implement the same workflow in tiddlywiki, you'd have to have a
"launcher" instance of tiddlywiki which would read a tiddlywiki instance
from disk as the "data file".

I seem to recall https://tiddlywiki.fission.app/ implements such a
launcher, 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 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  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 

Re: [tw5] Major updates to Chromium native file system saver plugin

[Frédéric Demers]

As inspiration, this seems to be a decent implementation of native file
storage API: https://bangle.io

On Fri, 18 Feb 2022 at 20:13, 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 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tiddlywiki/6ee85fa3-f495-4a11-874d-01aa02db7a52n%40googlegroups.com
> 
> .
>

-- 
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/CAAY2DnOq8LXuyC_4YJR6Q7KTU7%2Bek%3Ds_ZhGbYG_qa4PMEpir1A%40mail.gmail.com.

Re: [tw5] Major updates to Chromium native file system saver plugin

[TW Tones]

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 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/6ee85fa3-f495-4a11-874d-01aa02db7a52n%40googlegroups.com.

Re: [tw5] Major updates to Chromium native file system saver plugin

[PMario]

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 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/b9c172f4-1b18-42dc-a58e-ce570e98ef78n%40googlegroups.com.

Re: [tw5] Major updates to Chromium native file system saver plugin

[Dyllon Gagnier]

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 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/e24b643e-3c98-450d-9094-8d5872dac025n%40googlegroups.com.

Re: [tw5] Major updates to Chromium native file system saver plugin

[PMario]

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 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/fc92f43d-31fa-4d4c-91c2-b01bccca81e3n%40googlegroups.com.

Re: [tw5] Major updates to Chromium native file system saver plugin

[Dyllon Gagnier]

Good catch, reset should be working again (version 0.6.3). (sorry for the 
spam Brian, I kept replying to you instead of the whole chain).

On Saturday, February 5, 2022 at 4:14:39 PM UTC-8 brian@gmail.com wrote:

>   
>
>> On Saturday, February 5, 2022 at 7:09:35 AM UTC-8 brian@gmail.com 
>>> wrote:
>>>
>> [...] 
>>
>>> Also, when I click the "Reset file save location" button, nothing in the 
 indexdb gets deleted. The button doesn't seem to have any effect in spite 
 of the log messages:

 $:/plugins/slaymaker1907/browser-nativesaver/saver.js:495 Reseting file 
 saver...
 $:/plugins/slaymaker1907/browser-nativesaver/saver.js:506 Reset file 
 save location.


>> Does the reset button work for you? The only way I've been able to get 
>> the save location to reset is to use developer tools to clear out the 
>> indexdb.
>>
>
>
> I changed this line:
>
> window.indexedDB.deleteDatabase(UNIQUE_PLUGIN_ID);
>
> to this:
>
> window.indexedDB.deleteDatabase(DB_NAME);
>
>
> and now the reset button is working for me.
>

-- 
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/8fa77dd2-b1b2-43fc-8454-9d23bdc037f4n%40googlegroups.com.

Re: [tw5] Major updates to Chromium native file system saver plugin

[Brian Theado]

> On Saturday, February 5, 2022 at 7:09:35 AM UTC-8 brian@gmail.com
>> wrote:
>>
> [...]
>
>> Also, when I click the "Reset file save location" button, nothing in the
>>> indexdb gets deleted. The button doesn't seem to have any effect in spite
>>> of the log messages:
>>>
>>> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:495 Reseting file
>>> saver...
>>> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:506 Reset file
>>> save location.
>>>
>>>
> Does the reset button work for you? The only way I've been able to get the
> save location to reset is to use developer tools to clear out the indexdb.
>


I changed this line:

window.indexedDB.deleteDatabase(UNIQUE_PLUGIN_ID);

to this:

window.indexedDB.deleteDatabase(DB_NAME);


and now the reset button is working for me.

-- 
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/CAO5X8Czfhhnzi_NY-Y60FEMTM3D3HWT%3DSK0ZCyOb68heUBrbjQ%40mail.gmail.com.

Re: [tw5] Major updates to Chromium native file system saver plugin

[Brian Theado]

Dyllon,

On Sat, Feb 5, 2022 at 4:43 PM Dyllon Gagnier 
wrote:

> The modal is required even if using IndexedDB. We need a button click both
> to show the choose file/folder dialogue as well as getting write/read
> permission if using IndexedDB. If you have a wiki mostly for reading, you
> can click the "close" modal button to exit without setting up the file save
> location/file permissions.


I *commented* *out* the call to $tw.modal.display and the saving flow is
still working for me. If I clear the indexdb (via developer tools since the
reset button isn't working for me), then 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 to choose a file to save to.
   5. I choose the same file I already have open and I'm asked if I want to
   replace the file and I say yes
   6. The file saves

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?


> Thank you very much for finding the bug with the consistency check! I
> rewrote a chunk of that recently when adding the save trail. I have fixed
> this and pushed the fix to GitHub and the example wiki (plugin version
> 0.6.2). I tested it out by opening the example wiki in two tabs and it was
> able to detect when the file had changed unexpectedly.
>

Great, thanks for fixing it.


> On Saturday, February 5, 2022 at 7:09:35 AM UTC-8 brian@gmail.com
> wrote:
>
[...]

> Also, when I click the "Reset file save location" button, nothing in the
>> indexdb gets deleted. The button doesn't seem to have any effect in spite
>> of the log messages:
>>
>> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:495 Reseting file
>> saver...
>> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:506 Reset file save
>> location.
>>
>>
Does the reset button work for you? The only way I've been able to get the
save location to reset is to use developer tools to clear out the indexdb.

Brian

-- 
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/CAO5X8Cx3NCvJMyh5ZY2uKhVkYXv7vdm6mNrJFtCw_5vTPT8c2g%40mail.gmail.com.

Re: [tw5] Major updates to Chromium native file system saver plugin

['Mark S.' via TiddlyWiki]

This seems like it would be a real game changer.  About 75% of the browser 
usage today is Chromium based. But it needs a bit of documentation from the 
user perspective.

What are consequences of using or not using indexDB? What are the 
consequences of using or not using the consistency check?

Thanks!

On Saturday, February 5, 2022 at 1:43:36 PM UTC-8 dyllon...@gmail.com wrote:

> The modal is required even if using IndexedDB. We need a button click both 
> to show the choose file/folder dialogue as well as getting write/read 
> permission if using IndexedDB. If you have a wiki mostly for reading, you 
> can click the "close" modal button to exit without setting up the file save 
> location/file permissions.
>
> Thank you very much for finding the bug with the consistency check! I 
> rewrote a chunk of that recently when adding the save trail. I have fixed 
> this and pushed the fix to GitHub and the example wiki (plugin version 
> 0.6.2). I tested it out by opening the example wiki in two tabs and it was 
> able to detect when the file had changed unexpectedly.
>
> On Saturday, February 5, 2022 at 7:09:35 AM UTC-8 brian@gmail.com 
> wrote:
>
>> Dyllon,
>>
>> I'm unable to get the hash comparison to work. Every time I save, I see a 
>> log message about there being no known hash:
>>
>> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:464 Saving with 
>> method 'autosave'
>> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:77 Input saver 
>> style [] is not recognized, using default of SingleFile.
>> $:/core/modules/utils/logger.js:52  saver-handler: Saving wiki with 
>> method autosave through saver slaymaker1907/browser-nativesaver
>> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:379 No previous 
>> known hash to compare against
>> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:413 Creating 
>> writable...
>> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:415 Created writable
>> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:418 Wrote data 
>> successfully
>> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:422 Closed writable
>> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:485 Successfully 
>> saved to file system
>>
>>
>> I never see the "Computing hash of text to save..." message in the log.
>>
>> Also, when I click the "Reset file save location" button, nothing in the 
>> indexdb gets deleted. The button doesn't seem to have any effect in spite 
>> of the log messages:
>>
>> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:495 Reseting file 
>> saver...
>> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:506 Reset file save 
>> location.
>>
>> Brian
>>
>> On Fri, Feb 4, 2022 at 11:12 PM Brian Theado  wrote:
>>
>>> I tried it and it worked for me. Nice job. From both a file: url and a 
>>> localhost url I was able to save and reload. I was also able to save the 
>>> file handle in the indexdb. I didn't try any of the other new features.
>>>
>>> But even when I had the file handle saved in indexdb, the settings modal 
>>> still comes every reload.  I'm not sure I understand the intended workflow, 
>>> but it seems like it would be less confusing if the modal would only come 
>>> when the indexdb file handle is missing. Is that possible?
>>>
>>> Also, I notice you implemented the reset-file-saver message handler as a 
>>> TW widget. In other code (i.e. 
>>> https://github.com/Jermolene/TiddlyWiki5/blob/master/plugins/tiddlywiki/browser-storage/startup.js)
>>>  
>>> I've seen it implemented via a startup module. Any thoughts on that?
>>>
>>> On Fri, Feb 4, 2022 at 6:11 PM Dyllon Gagnier  
>>> wrote:
>>>
 This is a plugin I've been working on for a while that allows you to 
 save your wiki to the file system without downloading a new file each time 
 and without requiring an external program besides the browser. It 
 currently 
 only works in Chromium (desktop) browsers such as Edge/Chrome since they 
 are the only browsers which support the necessary APIs (though others may 
 support it once the APIs are fully standardized).

 You can see File System Access API | Can I use... Support tables for 
 HTML5, CSS3, etc  for 
 browsers which will probably work. I have not tested it on Safari so if 
 you 
 try it out there, let me know how it goes.

 I've implemented several new major features for  
 slaymaker1907/TW5-browser-nativesaver 
 (github.com)  
 for 
 those who are interested.

- By default, the plugin now checks for file consistency issues 
(such as having the same wiki open in multiple tabs). 
- I've softened a bit on the security implications of saving file 
handles to IndexedDB when the wiki is served from file://. You can now 
avoid selecting the file each time via a setting.
- In addition to the default 

Re: [tw5] Major updates to Chromium native file system saver plugin

[Dyllon Gagnier]

The modal is required even if using IndexedDB. We need a button click both 
to show the choose file/folder dialogue as well as getting write/read 
permission if using IndexedDB. If you have a wiki mostly for reading, you 
can click the "close" modal button to exit without setting up the file save 
location/file permissions.

Thank you very much for finding the bug with the consistency check! I 
rewrote a chunk of that recently when adding the save trail. I have fixed 
this and pushed the fix to GitHub and the example wiki (plugin version 
0.6.2). I tested it out by opening the example wiki in two tabs and it was 
able to detect when the file had changed unexpectedly.

On Saturday, February 5, 2022 at 7:09:35 AM UTC-8 brian@gmail.com wrote:

> Dyllon,
>
> I'm unable to get the hash comparison to work. Every time I save, I see a 
> log message about there being no known hash:
>
> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:464 Saving with 
> method 'autosave'
> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:77 Input saver style 
> [] is not recognized, using default of SingleFile.
> $:/core/modules/utils/logger.js:52  saver-handler: Saving wiki with method 
> autosave through saver slaymaker1907/browser-nativesaver
> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:379 No previous 
> known hash to compare against
> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:413 Creating 
> writable...
> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:415 Created writable
> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:418 Wrote data 
> successfully
> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:422 Closed writable
> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:485 Successfully 
> saved to file system
>
>
> I never see the "Computing hash of text to save..." message in the log.
>
> Also, when I click the "Reset file save location" button, nothing in the 
> indexdb gets deleted. The button doesn't seem to have any effect in spite 
> of the log messages:
>
> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:495 Reseting file 
> saver...
> $:/plugins/slaymaker1907/browser-nativesaver/saver.js:506 Reset file save 
> location.
>
> Brian
>
> On Fri, Feb 4, 2022 at 11:12 PM Brian Theado  wrote:
>
>> I tried it and it worked for me. Nice job. From both a file: url and a 
>> localhost url I was able to save and reload. I was also able to save the 
>> file handle in the indexdb. I didn't try any of the other new features.
>>
>> But even when I had the file handle saved in indexdb, the settings modal 
>> still comes every reload.  I'm not sure I understand the intended workflow, 
>> but it seems like it would be less confusing if the modal would only come 
>> when the indexdb file handle is missing. Is that possible?
>>
>> Also, I notice you implemented the reset-file-saver message handler as a 
>> TW widget. In other code (i.e. 
>> https://github.com/Jermolene/TiddlyWiki5/blob/master/plugins/tiddlywiki/browser-storage/startup.js)
>>  
>> I've seen it implemented via a startup module. Any thoughts on that?
>>
>> On Fri, Feb 4, 2022 at 6:11 PM Dyllon Gagnier  
>> wrote:
>>
>>> This is a plugin I've been working on for a while that allows you to 
>>> save your wiki to the file system without downloading a new file each time 
>>> and without requiring an external program besides the browser. It currently 
>>> only works in Chromium (desktop) browsers such as Edge/Chrome since they 
>>> are the only browsers which support the necessary APIs (though others may 
>>> support it once the APIs are fully standardized).
>>>
>>> You can see File System Access API | Can I use... Support tables for 
>>> HTML5, CSS3, etc  for 
>>> browsers which will probably work. I have not tested it on Safari so if you 
>>> try it out there, let me know how it goes.
>>>
>>> I've implemented several new major features for  
>>> slaymaker1907/TW5-browser-nativesaver 
>>> (github.com)  for 
>>> those who are interested.
>>>
>>>- By default, the plugin now checks for file consistency issues 
>>>(such as having the same wiki open in multiple tabs). 
>>>- I've softened a bit on the security implications of saving file 
>>>handles to IndexedDB when the wiki is served from file://. You can now 
>>>avoid selecting the file each time via a setting.
>>>- In addition to the default saver style, you can also have a save 
>>>trail of versions under a backups folder. It's a bit clunky though so I 
>>>would still recommend using a separate backup system for your wiki.
>>>- The plugin shows a settings modal at load time. The plugin needs 
>>>an interaction event (such as a click) to use parts of the file system 
>>> API 
>>>and I found it takes me out of the flow to have the file picker show up 
>>>after I've edited a tiddler.
>>>
>>> The new API for triggering 

Re: [tw5] Major updates to Chromium native file system saver plugin

[Brian Theado]

Dyllon,

I'm unable to get the hash comparison to work. Every time I save, I see a
log message about there being no known hash:

$:/plugins/slaymaker1907/browser-nativesaver/saver.js:464 Saving with
method 'autosave'
$:/plugins/slaymaker1907/browser-nativesaver/saver.js:77 Input saver style
[] is not recognized, using default of SingleFile.
$:/core/modules/utils/logger.js:52  saver-handler: Saving wiki with method
autosave through saver slaymaker1907/browser-nativesaver
$:/plugins/slaymaker1907/browser-nativesaver/saver.js:379 No previous known
hash to compare against
$:/plugins/slaymaker1907/browser-nativesaver/saver.js:413 Creating
writable...
$:/plugins/slaymaker1907/browser-nativesaver/saver.js:415 Created writable
$:/plugins/slaymaker1907/browser-nativesaver/saver.js:418 Wrote data
successfully
$:/plugins/slaymaker1907/browser-nativesaver/saver.js:422 Closed writable
$:/plugins/slaymaker1907/browser-nativesaver/saver.js:485 Successfully
saved to file system


I never see the "Computing hash of text to save..." message in the log.

Also, when I click the "Reset file save location" button, nothing in the
indexdb gets deleted. The button doesn't seem to have any effect in spite
of the log messages:

$:/plugins/slaymaker1907/browser-nativesaver/saver.js:495 Reseting file
saver...
$:/plugins/slaymaker1907/browser-nativesaver/saver.js:506 Reset file save
location.

Brian

On Fri, Feb 4, 2022 at 11:12 PM Brian Theado  wrote:

> I tried it and it worked for me. Nice job. From both a file: url and a
> localhost url I was able to save and reload. I was also able to save the
> file handle in the indexdb. I didn't try any of the other new features.
>
> But even when I had the file handle saved in indexdb, the settings modal
> still comes every reload.  I'm not sure I understand the intended workflow,
> but it seems like it would be less confusing if the modal would only come
> when the indexdb file handle is missing. Is that possible?
>
> Also, I notice you implemented the reset-file-saver message handler as a
> TW widget. In other code (i.e.
> https://github.com/Jermolene/TiddlyWiki5/blob/master/plugins/tiddlywiki/browser-storage/startup.js)
> I've seen it implemented via a startup module. Any thoughts on that?
>
> On Fri, Feb 4, 2022 at 6:11 PM Dyllon Gagnier 
> wrote:
>
>> This is a plugin I've been working on for a while that allows you to save
>> your wiki to the file system without downloading a new file each time and
>> without requiring an external program besides the browser. It currently
>> only works in Chromium (desktop) browsers such as Edge/Chrome since they
>> are the only browsers which support the necessary APIs (though others may
>> support it once the APIs are fully standardized).
>>
>> You can see File System Access API | Can I use... Support tables for
>> HTML5, CSS3, etc  for
>> browsers which will probably work. I have not tested it on Safari so if you
>> try it out there, let me know how it goes.
>>
>> I've implemented several new major features for  
>> slaymaker1907/TW5-browser-nativesaver
>> (github.com)  for
>> those who are interested.
>>
>>- By default, the plugin now checks for file consistency issues (such
>>as having the same wiki open in multiple tabs).
>>- I've softened a bit on the security implications of saving file
>>handles to IndexedDB when the wiki is served from file://. You can now
>>avoid selecting the file each time via a setting.
>>- In addition to the default saver style, you can also have a save
>>trail of versions under a backups folder. It's a bit clunky though so I
>>would still recommend using a separate backup system for your wiki.
>>- The plugin shows a settings modal at load time. The plugin needs an
>>interaction event (such as a click) to use parts of the file system API 
>> and
>>I found it takes me out of the flow to have the file picker show up after
>>I've edited a tiddler.
>>
>> The new API for triggering modals from JS is pretty nice, but let me know
>> if there is a way to trigger modals in a way that works with older wikis.
>> I'm using "$tw.modal.display(tiddlerTitle)", but this seems to be new to
>> 5.2.1.
>>
>> --
>> 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/92d16d9f-002e-4417-a1fa-42e869d7c143n%40googlegroups.com
>> 
>> .
>>
>

-- 
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 

Re: [tw5] Major updates to Chromium native file system saver plugin

[Brian Theado]

I tried it and it worked for me. Nice job. From both a file: url and a
localhost url I was able to save and reload. I was also able to save the
file handle in the indexdb. I didn't try any of the other new features.

But even when I had the file handle saved in indexdb, the settings modal
still comes every reload.  I'm not sure I understand the intended workflow,
but it seems like it would be less confusing if the modal would only come
when the indexdb file handle is missing. Is that possible?

Also, I notice you implemented the reset-file-saver message handler as a TW
widget. In other code (i.e.
https://github.com/Jermolene/TiddlyWiki5/blob/master/plugins/tiddlywiki/browser-storage/startup.js)
I've seen it implemented via a startup module. Any thoughts on that?

On Fri, Feb 4, 2022 at 6:11 PM Dyllon Gagnier 
wrote:

> This is a plugin I've been working on for a while that allows you to save
> your wiki to the file system without downloading a new file each time and
> without requiring an external program besides the browser. It currently
> only works in Chromium (desktop) browsers such as Edge/Chrome since they
> are the only browsers which support the necessary APIs (though others may
> support it once the APIs are fully standardized).
>
> You can see File System Access API | Can I use... Support tables for
> HTML5, CSS3, etc  for browsers
> which will probably work. I have not tested it on Safari so if you try it
> out there, let me know how it goes.
>
> I've implemented several new major features for  
> slaymaker1907/TW5-browser-nativesaver
> (github.com)  for
> those who are interested.
>
>- By default, the plugin now checks for file consistency issues (such
>as having the same wiki open in multiple tabs).
>- I've softened a bit on the security implications of saving file
>handles to IndexedDB when the wiki is served from file://. You can now
>avoid selecting the file each time via a setting.
>- In addition to the default saver style, you can also have a save
>trail of versions under a backups folder. It's a bit clunky though so I
>would still recommend using a separate backup system for your wiki.
>- The plugin shows a settings modal at load time. The plugin needs an
>interaction event (such as a click) to use parts of the file system API and
>I found it takes me out of the flow to have the file picker show up after
>I've edited a tiddler.
>
> The new API for triggering modals from JS is pretty nice, but let me know
> if there is a way to trigger modals in a way that works with older wikis.
> I'm using "$tw.modal.display(tiddlerTitle)", but this seems to be new to
> 5.2.1.
>
> --
> 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/92d16d9f-002e-4417-a1fa-42e869d7c143n%40googlegroups.com
> 
> .
>

-- 
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/CAO5X8CwWntuFVF1WgfYjiWmXiWE1OFsMTMktmEDN3J9nUFwqzw%40mail.gmail.com.

[tw5] Major updates to Chromium native file system saver plugin

[Dyllon Gagnier]

This is a plugin I've been working on for a while that allows you to save 
your wiki to the file system without downloading a new file each time and 
without requiring an external program besides the browser. It currently 
only works in Chromium (desktop) browsers such as Edge/Chrome since they 
are the only browsers which support the necessary APIs (though others may 
support it once the APIs are fully standardized).

You can see File System Access API | Can I use... Support tables for HTML5, 
CSS3, etc  for browsers which 
will probably work. I have not tested it on Safari so if you try it out 
there, let me know how it goes.

I've implemented several new major features for  
slaymaker1907/TW5-browser-nativesaver 
(github.com)  for 
those who are interested.

   - By default, the plugin now checks for file consistency issues (such as 
   having the same wiki open in multiple tabs). 
   - I've softened a bit on the security implications of saving file 
   handles to IndexedDB when the wiki is served from file://. You can now 
   avoid selecting the file each time via a setting.
   - In addition to the default saver style, you can also have a save trail 
   of versions under a backups folder. It's a bit clunky though so I would 
   still recommend using a separate backup system for your wiki.
   - The plugin shows a settings modal at load time. The plugin needs an 
   interaction event (such as a click) to use parts of the file system API and 
   I found it takes me out of the flow to have the file picker show up after 
   I've edited a tiddler.

The new API for triggering modals from JS is pretty nice, but let me know 
if there is a way to trigger modals in a way that works with older wikis. 
I'm using "$tw.modal.display(tiddlerTitle)", but this seems to be new to 
5.2.1.

-- 
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/92d16d9f-002e-4417-a1fa-42e869d7c143n%40googlegroups.com.