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 dialogue.
Does this one have any technical barrier for you? Sounds like you have it figured out. Sounds like a useful approach as long as the tiddlywiki is loaded from a file url.
The only issue is the user needs to be told and/or reminded they can use crtl-v in the file dialogue. Its a trick and not commonly used, although easy to use. This is why if we can rely on local storage for small changes (no auto-save) and trigger a modal when saving we can present a modal to guide the user and address the need for the button click.
[…]
-
Custom Target/tab: If we want to protect against opening the same wiki in a tab, one trick is after the first save (knowing the full path and filename) we can construct a html link with an appropriate target attribute, then navigate to that (if possible closing the original tab), thus the wiki is now running in a tab with a named target.
What needs to know the full path and filename here? The user will know and the browser will know, but the functionality running in the web page (i.e. the tiddlywiki instance) will not know. It only has access to the filename minus the directory location. The directory location is hidden from it.
The full path and directory is known by a tiddlywiki loaded from file. If a user stores the full path and filename in a wiki it also known to that wiki (eg store in a cookie)
The user has the information required to construct the html link you mention, but the tiddlywiki page does not.
[…]
Unless it is given and stores the full path and filename, however if we have a bookmarklet it can store the the full path and filename including a target tab. Clicking the same bookmark will always open in the same tab avoiding the opening of multiple tabs and the global file:// issues(see next notes)
-
- This should help given the global file:// issues
I’m not sure what you mean here.
Just the “problem” with all file tiddlywikis having access to the same file:// domain. However it could be used for communication between wikis if we wanted. However as a rule we want a file:// tiddly wiki opened only once in a browser (or any browser) so there is not “contention”
-
Bookmarklet: Perhaps extending the value of Custom Target/tab and because there is value using it, we can consider the use of a bookmarklet both with a target and a payload if necessary.
What do you mean by “payload”? Could you give an example?
- An example may be so if the user returned to the source site, published on the internet the bookmarklette can recall you already have a local copy and with a click. When saving from the source URL for the first time we could prompt the user to use their saved bookmark if they want to access their local copy, to not create a new one, or override and existing one.
I’m not sure how the bookmarklet would know you already have a local copy
The bookmarklet only exists if you created it from a local copy, it contains the link and target but can include a payload ie a tiddler containing details about the local copy. Thus the bookmarklete knows you have a local copy.
A trick that can be used is on arriving at an internet site we want to save a local copy we use the existing mechanism to save the local copy, then we can open that copy (ideally closing the internet tab #1). Once you have opened the local copy, you have access to the full path. Now so we do not loose the link to the local copy we can provide a link (we build it and can add a payload) for users to drag into their favorites and bookmarks.
#1 - before closing the internet tab
-
Save a cookie (or more) for that site indicating the existence of a local copy.
-
When our internet wiki loads it can test for these cookies, and advise the user a local copy exists.
- It can then ask ONCE the bookmark to be clicked, dropping the “payload tiddler”, then the internet site can also save the full path into the cookie(s)
-
Subsequent visits to the internet site in the same browser can list all local copies of itself and provide links to its target tab OR allow new copies to be saved locally.
I know my replies are somewhat convoluted but this is a somewhat complex problem with substantial features if we can achieve it. I believe we just need a little more tweaking and a strong guided workflow.
