Yakov, Timimi, Is better than TiddlyFox. Once the "FireFox" plugin and local piece is installed, and firefox is your default browser double clicking a html file (aka Tiddlywiki) anywhere on your desktop will open in the browser and can save back to that file with no other action.
To save, it just saves it in place. If you download any internet hosted file wiki to any location using the default download file saver then open that file you can edit and save it in firefox. Mario has some youtube videos on using github that may help https://www.youtube.com/user/pmariojo/search?query=github Regards Tony On Monday, April 1, 2019 at 8:47:55 AM UTC+11, Yakov wrote: > > Hi Tony, > > thanks for sharing. Did I get the description right: is Timimi able to > save TW5 in any folder, unlike file-backups or SaveTiddler which only allow > to save only TWs in the browser download folder? That sounds very > intriguing and if that's the case, I'll test it out and have a closer look > at the source. > > However, I really hope somebody among TW5 ecosystem developers will join > me to make simple and clear docs for this (also AFAIK I can't create a new > repo in https://github.com/TiddlyWiki/ , I only have access to > https://github.com/TiddlyWiki/TiddlyWiki/ to maintain the core). > > Best regards, > Yakov. > > четверг, 28 марта 2019 г., 5:17:43 UTC+3 пользователь TonyM написал: >> >> Yakov, >> >> I do not have the skills to help you but would point out how Timimi is a >> Tiddlyfox replacement, that perhaps only works with TW5 however it shows >> the path to such saving in modern browsers. >> >> Regards >> Tony >> >> On Monday, March 25, 2019 at 1:58:40 AM UTC+11, Yakov wrote: >>> >>> Hey everybody, >>> >>> in the latest release >>> <https://groups.google.com/forum/#!topic/tiddlywikiclassic/GDBYezPtdlg> >>> of TiddlyWiki Classic I've fixed the upgrading engine and now it's time to >>> deal with saving >>> <https://groups.google.com/forum/#!topic/tiddlywikiclassic/SiD6QnG9wAM> >>> more consistently. That's where I'd like not only to ask about some dev >>> aspects but also discuss some conventions and create docs for consistent >>> support of saving both TWC and TW5. >>> >>> I'll start with TiddlyFox since it is still used by many users (with >>> either FireFox 56- or Pale Moon, WaterFox and other FF forks). One thing >>> about it is building the xpi: I've read about building it a little and the >>> crucial quesion is: is it still possible to create signed xpi, or updating >>> TiddlyFox is impossible in principle? >>> >>> If it's not, I'd only like to ask Jeremy to add 2.x tags to the repo and >>> attach xpi files to the github releases; or add me to the repo and I'll do >>> that myself. Otherwise, I'd like to contribute a bit more and have some >>> more questions. >>> >>> Next and the main point of this thread is: both TWC and TW5 have many >>> supporting solutions (native apps, servers, browser plugins etc) for saving >>> but I'm not aware of docs that describe how actually one supports saving >>> (and may be more functionality) of both TWC and TW5. For instance, >>> MainTiddlyServer <https://yakovl.github.io/MainTiddlyServer/> could be >>> extended a bit so that it fits the php server gap >>> <https://github.com/TiddlyWiki/php-server>, but I (as a developer of >>> TWC extensions, MTS and maintainer of the core) am not really aware of how >>> to support TW5 correctly; likewise, the aTW >>> <https://github.com/TiddlyWiki/aTW> saver for Android supports only TW5 >>> (as far as I know), but I'd like to participate and support TWC as well, >>> yet I still didn't even get an answer >>> <https://github.com/TiddlyWiki/aTW/issues/1#issuecomment-459076550> >>> about the app status (and I suspect Simon may be reluctant to support TWC >>> without nice docs describing that). Finally, it seems every time one tries >>> to support saving in their software, they invent some new implementation >>> which (this diversity) is difficult to follow and the ecosystem is quite >>> difficult to maintain. >>> >>> Thus, it seems to me that we really need 2 things: >>> >>> - nice docs describing how to support saving of TWC, TW5 (and, in >>> perpective, more features like image uploading and more) >>> - core libraries in different languages (js for browser plugins? js >>> for node, PHP, Java/Android, Swift/iOS, may be more) which one can use >>> for >>> developing new solutions >>> >>> Now this thread is mostly about the first part, the docs (and by the way >>> saving is not the only thing which would be nice to document; think, for >>> example, of the .tid format which is not described anywhere, at least >>> Jeremy wrote so some months ago). >>> >>> My proposal consists of 2 parts: >>> >>> 1. create a repo in the TiddlyWiki <https://github.com/TiddlyWiki/> >>> org @github (I'd like to be a member to contribute) >>> 2. start building docs >>> >>> For the second part, I now have a draft based on what I've learned from >>> the TiddlyFox sources, see it below the main post. I invite you to comment >>> it, correct where I'm wrong, fill the gaps, especially about TW5. >>> >>> >>> Best regards, >>> >>> Yakov. >>> >>> >>> == first draft of "how to support TW saving" docs == >>> >>> >>> To support TW saving, it is to be desided: >>> >>> 1. how to recognize a TW? >>> 2. when to inject new JS? >>> 3. what JS to inject (and where)? >>> >>> >>> (and also the "protocol" and the "back-end logic" stuff) >>> >>> >>> *How to recognize a TW?* >>> >>> First, let's note that the simplest implementation can omit TW >>> recognition: just ask whether to inject JS or inject it into every html >>> "served" with the saver app. >>> >>> Looking at TiddlyFox code, it seems the following procedure is ok: >>> >>> - to recognize TWC, check whether there's #storeArea element [TF >>> searches DOM, not source], #versionArea element and the latter >>> contains the word "TiddlyWiki" >>> - to recognize TW5, check whether among <meta> elements there's one >>> with name "application-name" and content "TiddlyWiki" >>> >>> This surely can give false positives which seems to be ok; this also >>> doesn't support "pure store" format. >>> >>> >>> *When (and where) to inject new JS?* >>> >>> this section is to be written yet. Notes: >>> >>> - MainTiddlyServer injects JS bits into the TWC code before serving >>> it and strips those back when saves "the whole thing" (it can also send >>> save increments); some modifications (like support of incremental >>> saving) >>> are made as hijacks which are done in loadPlugins >>> <https://github.com/YakovL/MainTiddlyServer/blob/master/index.php#L467> >>> so that the store is ready >>> - server-side implementations (that inject JS into TW so that >>> user doesn't have to install a plugin into TW) also need to decide >>> where to >>> inject JS, see next section >>> - not sure whether TiddlyFox adds JS on load or eariler (probably >>> the latter) >>> - neither I am sure of the exact moment tiddly-node-saver uses >>> >>> <https://github.com/fallwest/tiddly-node-saver/blob/master/server.js#L27> >>> although the approach looks interesting >>> - same for TiddlyDesktop overwriting >>> >>> <https://github.com/Jermolene/TiddlyDesktop/blob/ffd0c7be4d4220a67211e3b18ece208d11d305e4/source/js/utils/saving.js#L19> >>> >>> >>> *What JS to inject (and where)?* >>> >>> For now, I'm describing some existing approaches instead of a >>> "canonical" one to be proposed. >>> >>> >>> TiddlyFox overwrites >>> <https://github.com/TiddlyWiki/TiddlyFox/blob/master/data/inject.js#L52> >>> window.mozillaSaveFile and window.mozillaLoadFile with new >>> implementations and also sets window.convertUriToUTF8 and >>> window.convertUnicodeToFileFormat to plain s => s functions (needed for >>> TWc before 2.9.2). This works *for TWC* and seems to be enough for bare >>> loading/saving functionality. One thing to add here is overwriting the >>> config.options.chkHttpReadOnly option if TW is served via http(s): >>> instead of file: scheme. >>> >>> >>> A similar set of changes is implemented >>> <https://github.com/fallwest/tiddly-node-saver/blob/00444358fb4d77b8ca0b8115403e61143f065f66/saveScripts.js> >>> >>> in tiddly-node-saver, it's simpler (window.saveFile is -overwritten-, >>> loading is not implemented at all, chkHttpReadOnly is set to false). >>> Actually window.saveFile is not overwritten but rather defined and I >>> suspect it relies on the following definition in TWC core: >>> >>> >>> window.saveFile = window.saveFile || function(fileUrl,content) >>> >>> >>> which substituted this: >>> >>> >>> function saveFile(fileUrl,content) >>> >>> >>> in 2.7.0 which is a quite sane limitation. >>> >>> >>> I haven't quite figured the approach >>> <https://github.com/Jermolene/TiddlyDesktop/blob/master/source/js/utils/saving.js> >>> >>> of TiddlyDesktop yet. >>> >>> >>> Unlike most solutions for local usages only, MTS is supposed to be used >>> on servers as well as locally, that's why it is more strict and currently >>> doesn't support saving arbitrary files. Instead, it injects >>> <https://github.com/YakovL/MainTiddlyServer/blob/master/index.php#L510> >>> "return saveOnlineChanges();" into saveChanges (and also inject >>> <https://github.com/YakovL/MainTiddlyServer/blob/master/index.php#L505> >>> the definitions before "function saveMain(" and changes >>> <https://github.com/YakovL/MainTiddlyServer/blob/master/index.php#L513> >>> the default value of chkHttpReadOnly, but now I see this should be >>> refactored since there are better approaches). >>> >>> >>> As *for TW5*, I'm not really sure about the exact stack, but it seems >>> for saving, a handler of the "tiddlywiki-save-file" custom event should >>> be added. The handler should expect the "event" (first argument) to have >>> .path and .content properties which should hold (local?) path to the >>> file to save and (UTF-8?) content string of the file. Not sure if some sort >>> of "file-save-success" event is supported to notify the core that the file >>> was actually saved (and TiddlyFox actually has a bug to always report that >>> TW was saved, even if it was on a USB storage which was removed before >>> saving, because the injected saver always returns true >>> <https://github.com/TiddlyWiki/TiddlyFox/blob/eb4c0d9822cf8beffe27a7cacb3b00c2d18e3771/data/inject.js#L26> >>> ). >>> >>> >>> *Further considerations* >>> >>> There's a number of topics that should be covered as well, mostly after >>> those above are, but some of them will affect architecture and hence should >>> be considered anyway (can affect the core, especially in case of TWC; I'm >>> ready to adapt it to better architecture): >>> >>> - sync vs async saving >>> - full saving vs sending changes, shortcuts for backuping (sending >>> full file to backup vs sending "copy file A into B" message) >>> - protocol layer (shouldn't necessarily be uniform, but >>> recommendations can facilitate development of new tools) >>> - streaming changes via websockets and sync editing >>> - security consideratinos >>> - server logic (authorization & roles, ..) >>> - federation (including content from other TWs, saving it back) >>> - advanced features (image uploading, integration with git etc) >>> >>> ==== >>> >>> Looks like that's all I've gathered for now. Again, contributions are >>> very much welcome. >>> >> -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/tiddlywikidev. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/432edc28-a801-40e9-83ba-d1e23dc0de70%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
