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

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.

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

*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

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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;

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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