- This is true, but we can also copy a path/folder into our wiki then use it to prefix the subsequent “filenames we import”.
- Thus we can “add files from any accessible path” we just need to do it a folder at a time, with a path prefix captured for each.
- Smart design would allow this prefix to be modified in future to indicate files moving to another path. Perhaps using relink to do this?.
I am actually doing a lot in this space, one key trick is to store the full path and filename in tiddlywiki, then just before opening an “import or save dialogue” copy the full path and file name to the clipboard, then pasting this into the open or save dialogue eg Ctrl-V in windows.
- I primarily do this with JSON packages to save an updated version or load the latest version.
- Capture the full path once and its available indefinitely.
I can imagine a custom drop zone as @wincent has created, one that bypasses the import process, but in the target wiki and also with the ability to set the path to be applied to subsequent file drops.
- in TiddlyWiki you use the Browse widget, then find the folder, r-click and copy path, cancel return to the wiki and paste the path. #1
- Then on the next browse or download operation the button also uses tm-copy-to-clipboard to automatically copy the saved path to the clipboard and paste it if you need to, in your open or save dialogue to navigate to that path.
#1 There may be other effective ways to collect full paths for locations containing files within the browser, because you can see folder structures in browser tabs using the File:// protocol
- A “browser add on” to support the copy of a full path and/or filename from this screen would be a useful way to capture and store full paths in ones wiki.
- Similar method’s could be used for URL on hosted wikis. eg
mydomain.com/images/
There are additional caveats and considerations using this approach to keep in mind, but it does add powerful interactions with the local file system,
