Ciao Tony M.
Thanks for the useful thoughts!
*Auto-Collation of paths to Wikis under a "Wikis Folder"? *
> Now if we have document folders that contain only tiddlywiki html files we
> could use the fact that mywiki.html exists in these folder to look for
> mywiki.html in the browser download folder(s). Add a new wiki to this
> folder and it automatically joins those to be collected.
>
Its a neat idea. But is it realistic? Possible issues ...
- Whilst I keep my single-file wikis largely nested under one directory
I also have other ".html / .htm" files in there too (e.g. output of static
exports of TW) which would get erroneously listed under that system.
- It suggests a user have a specific "TW Folder" (TWF) to store TW
under. And you have "exceptions" too (i.e. paths outwithTWF could be
manually added) ...
- ... but with any "exception" you'd be back to the existing issue of
selecting exact addresses. Overall, I think ONE method (manual) for adding
candidate wiki is probably less complex to understand than having TWO (auto
+ manual "exceptions") in the end?
- I don't think one should assume users actually organise their wiki
this way as a norm? I mean, I don't know where users store their wiki.
*Immediate Move From Downloads? *
If a tiddlywiki is collected and removed from downloads immediately, it
> will always save as the same and original filename. No confusing versions
> or overwrite prompts.
>
Clever idea! Though, issues I think?
- A major issue would be TIMING. You'd need to have a script
continuously polling every few seconds the downloads directory for new
downloads of "mywiki.html".
We need to cater for versions if the batch is not running for a while, but
> it can just iterate the versions the same way with moves.
Exactly!
- IMO users should be able to restore without having to constantly run a
script ...
- ... which brings one back to a method to locate the latest and copy
and rename it--*which is what Mark S.' script does already*
- Again, you seem to be suggesting TWO methods---one where you rapidly
move a download save back with no name change, and---a second that renames
and copy/moves back. Why not just ONE method? Since the second method
removes the need for the first, why have the first?
*Changing Content of Downloads?*
An additional point is perhaps more philosophical...
- In using a method to *restore* wiki from downloads I'm uncomfortable
with idea we'd also be *managing files in Downloads. *Changing the
content of downloads seems more for a *dedicated backup system*, or
*explicit
deletion* by the end user?
- In short, a "restore" script should *not *change anything in downloads?
*Wiki Pathing Collation Tool!*
It would be possible to run a batch command in any folder that adds
> (appends) that folder to those to be scanned for in download folders. Even
> better would be to add this to the desktops file manager to get a r-click
> to select that folder. This iteration can also scan for subfolders.
Neat idea! Like it!
- What you point to is some method / tool to *more easily identify Wiki
and get their paths into a settings file? *
Yes?
- I guess a standard "file picker" might also work? Maybe as part of a
"configuration tool?" (I believe that might be possible via PowerShell? I
just don't understand PS well enough to know how to do it).
*TW Files With Extension ".TW"*
> In windows at least a simple registry entry can associate .tw files with
> your default browser and clicking a tw file will open as usual in the
> browser. If this is done tw files could be placed in any folder with any
> files including other html files and you could even auto detect downloaded
> tw files and move them to a default folder.
>
> With .tw files you could select your documents folder and it and all its
> sub folders could be scanned to locate .tw files to check for in downloads,
> and to identify where they beling. Again reducing the need for
> configuration.
>
I seen you mentioned the File Type *".tw"* before in other threads. I think
its interesting--as are many other of your ideas about leveraging the O/S &
browsers to get a lovely system. Simple points ...
- The current PS1 script could be modified, I think, to accept a range
of extensions eventually. Like *.html, .htm, .hta, .tw ...*
- In fact, I see no reason that it can't be totally agnostic about what
file types it restores
*Download Naming*
> A recent change to tiddlywiki allows you to set the download filename
> before you download the first time. You could do this to ensure it is
> unique and maybe even name it to a .tw file. Then it would automagicaly be
> managed by the local scripts.
>
Useful info! I take a look.
*Universal?*
> Whilst these solutions aim to be universal we do need a different one for
> each operating system, so will it ever be universal?
>
*My bad* for not making clearer what I meant by "universal". I meant ...
- Working in alignment with the standardised download saving and save
naming mechanisms that all modern browsers support
- In other words "universal" as "one standard method for any browser"
But you are right, that, if this approach, currently limited to a Windows
scripting language (PowerShell) gets somewhere it would need writing in
other platforms' script languages. But ...
- ... its not exactly settled yet what it is on Windows. Though the
basic "restore" function is there and working. Other platforms later?
- Installation territory et al. Well that seems like "Repository"
territory. Not there yet. The approach needs a lot more interest and input
I think to begin to approach that.
*Compatability with Existing TW Savers? *
A multiple os intaller could solve this. Having .tw files could make it
> possible to auto configure everything.
Using the above should be compatible with timimi being installed because
> once it is running you just open the wikis and timimi handles the save and
> no download occurs. Timimi already works with .tw files.
>
> This process should work along with tiddlydesktop and tiddlyserver as well
>
>
Yeah, the method using Mark S.' script at its core is compatible with other
saving mechanism in TW. For the simple reason ...
- If you use a TW dedicated saver then *no* TiddlyWiki will get written
to Downloads so co-existence with TW savers does not occur.
- But, say you worked with a TW in Edge where normally you run in
Firefox with Timimi ... You could use the "Nine-lives" script to restore
the Edge edited version and just go back to Firefox and carry on from where
Edge left off, no problem ...
- Basically the approach is *Complementary* to other methods of saving
in TW. And its also *Additive *so you can include any browser brand.
Using *One *method for all of them.
Tony, thanks very much for your very useful post. Please let me know if I
misunderstood anything
Best wishes
Josiah
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/1eee53e5-069d-4f9a-b5fd-4c5d64f3280e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
