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.
--
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 tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/6c6d3b0d-4bd6-4ec9-9b31-54801831b7d4n%40googlegroups.com.
