This is mostly for Eric:
This tiddlywiki commit
https://github.com/TiddlyWiki/tiddlywiki/commit/89ef40fe82973a0aae17367f08286f5e087862f7
implies that the new HTML5 download handling could allow saving the
content of any tiddlywiki being viewed in the browser to disk, even if
the
On May 25, 10:16 am, chris.d...@gmail.com wrote:
This is mostly for Eric:
This tiddlywiki commit
https://github.com/TiddlyWiki/tiddlywiki/commit/89ef40fe82973a0aae173...
implies that the new HTML5 download handling could allow saving the
content of any tiddlywiki being viewed in the
On Sat, 25 May 2013, Eric Shulman wrote:
Thanks for the quick response.
saveChanges() calls on saveMain() which, in turn, calls on
fileSave(). fileSave() uses a 'fallack cascade' to attempt to save
the file using various forms of browser-specific *local file I/O* (moz/
TiddlyFox,
Given the stack of options for saving, why is the
HTML5DownloadFileSave last? What I mean is, what is the disadvantage
compared to the others?
Should it perhaps be first?
The existing direct file I/O functions are synchronous, and return
true/false if they actually succeed/fail to save the