Re: [tw5] Announcing TiddlyMarker v0.1.0-alpha for Firefox

[Arlen Beiler]

To use this with TiddlyServer you just need to make sure you are making all
requests relative to the tiddlywiki you are targeting. TiddlyServer loads
NodeJS instances dynamically as they are requested. So most likely you are
making the call to the root path ("http://localhost/;) and usually that is
not where the tiddlywiki is mounted. Instead you need to change those calls
to the path "http://localhost/personal/notes/; or whatever the path to your
wiki is. That's just my guess without really taking a look at it or trying
anything out. I just saw you said you were using the TW webserver api.

On Wed, Jun 3, 2020 at 2:40 AM Yestin Harrison 
wrote:

> I've been working on a browser extension to suit a particular manner of
> bookmarking with TiddlyWiki, unimaginatively titled TiddlyMarker. The basic
> idea is a simple button that produces a bookmark tiddler from the current
> tab, with various ways of getting that tiddler into a wiki, and flexibility
> as to its structure. Currently, the two modes of saving work via the TW
> webserver API, and simple browser downloads, respectively.
>
> Anyone who wants to give it a try can clone the repository at
> https://git.ylh.io/tiddlymarker and follow the README to get up and
> running.
>
> Of interest to developers: the code is a bit of a mess (JS isn't really my
> forte), and it's missing the planned saving mode for adding to an already
> open TiddlyWiki tab; getting the extension to play nice with $tw in the
> page context is proving to be a bit of a faff, especially in a way that can
> easily be ported to Chrome (that's planned too). Commented sections show
> the beginnings of such a mode, and patches are welcome; email them to
> yes...@ylh.io.
>
> It's in a reasonable working state, and I'm now soliciting feedback before
> I port it to Chrome and package it for Mozilla and Google.
> Enjoy!
>
> --
> 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/6c601e92-9508-4b4a-9b75-2b6d2f21d68f%40googlegroups.com
> 
> .
>

-- 
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/CAJ1vdSTtBHcUpzvWYMt1DzRv_paSP1Kfz9xjKsX1U5M2MpEoew%40mail.gmail.com.

Re: [tw5] Announcing TiddlyMarker v0.1.0-alpha for Firefox

[amreus]

Oh, and thank you for creating this plugin!


On Thursday, October 15, 2020 at 8:02:16 PM UTC-4 amreus wrote:

> I made and quickly deleted a post asking about using a prefix ore template 
> for tiddler naming.  
>
> I found the answer in the tiddlymarks options page. You can construct the 
> fields as you wish in the Formatting section. Here is an example of using a 
> system tiddler for the bookmark tiddler:
>
> [image: 2020-10-15_195926.png]
>
>
>
> On Monday, June 8, 2020 at 2:57:24 AM UTC-4 Yestin Harrison wrote:
>
>> Well, 0.3.0 is live on AMO. Besides fixing a rather nasty bug that 
>> rendered the popup inoperable under certain circumstances, I took it 
>> as an opportunity to make the download dialog opt-in (default off), 
>> and add an explanatory label to the server URL. 
>>
>> As far as large features are concerned, there's one primary issue – 
>> there are rather strict requirements on what execution context can 
>> trigger the popup. This is ostensibly to protect users from surprising 
>> behaviour, but the long and of it is that as soon as I await something 
>> (such as making sure a tab is opened and then loaded, as would be the 
>> case for a context menu item to bookmark a link), I no longer have the 
>> ability to bring up the popup. That is to say, anything that depends 
>> on a resource that is not the current tab would have to either 
>> unconditionally run in “quick mode” with no ability for the user to 
>> edit anything, or instantiate some different mechanism within the page 
>> (i.e. port the popup to instantiate in a content script). 
>>
>> The latter would work with some effort, but it has the unfortunate 
>> property that it would all be for *just* links. The lovely thing about 
>> the context menu API is that among its supported contexts are native 
>> browser bookmarks, which would be *incredibly* convenient for porting 
>> over existing bookmarks. Frustratingly enough, though, doing anything 
>> meaningful with those is just out of reach. With no corresponding page 
>> context to run in, and no way to signal anything important before 
>> bringing up the popup in a manner programmatically indistinguishable 
>> from an ordinary click on the extension button (!), it would have no 
>> way of presenting any user interface. 
>>
>> I've already had to hack around this strict behaviour to get the popup 
>> to be whatsoever conditional, but I believe that's the most I can do 
>> there. If there are any JS gurus reading who know some reason what I 
>> wrote might be wrong, please do let me know – I'd love to implement 
>> something like this if the extension APIs allowed me to. 
>>
>> With the disappointing technical bits out of the way, some good news: 
>> page previews are actually incredibly easy to get from the tabs API, 
>> so some form of support for that would be doable. I'm mulling over 
>> ways to make favicon formatting more customisable. One potential 
>> solution is to just expose a snapshot of the whole tab data structure 
>> to both formatting functions and throw the user a link to MDN if they 
>> want to mess around. Another is to split the favicon title into its 
>> own formatting function, and evaluate it at slightly different points 
>> than where the current two are, so it could be intercepted when the 
>> popup is brought up. 
>>
>> Either way, the addon is in quite a healthy state at the moment, and 
>> should get even handier and more flexible very soon. 
>>
>

-- 
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/72d44374-457c-4c81-b50b-9ab983117d22n%40googlegroups.com.

Re: [tw5] Announcing TiddlyMarker v0.1.0-alpha for Firefox

[amreus]

I made and quickly deleted a post asking about using a prefix ore template 
for tiddler naming.  

I found the answer in the tiddlymarks options page. You can construct the 
fields as you wish in the Formatting section. Here is an example of using a 
system tiddler for the bookmark tiddler:

[image: 2020-10-15_195926.png]



On Monday, June 8, 2020 at 2:57:24 AM UTC-4 Yestin Harrison wrote:

> Well, 0.3.0 is live on AMO. Besides fixing a rather nasty bug that
> rendered the popup inoperable under certain circumstances, I took it
> as an opportunity to make the download dialog opt-in (default off),
> and add an explanatory label to the server URL.
>
> As far as large features are concerned, there's one primary issue –
> there are rather strict requirements on what execution context can
> trigger the popup. This is ostensibly to protect users from surprising
> behaviour, but the long and of it is that as soon as I await something
> (such as making sure a tab is opened and then loaded, as would be the
> case for a context menu item to bookmark a link), I no longer have the
> ability to bring up the popup. That is to say, anything that depends
> on a resource that is not the current tab would have to either
> unconditionally run in “quick mode” with no ability for the user to
> edit anything, or instantiate some different mechanism within the page
> (i.e. port the popup to instantiate in a content script).
>
> The latter would work with some effort, but it has the unfortunate
> property that it would all be for *just* links. The lovely thing about
> the context menu API is that among its supported contexts are native
> browser bookmarks, which would be *incredibly* convenient for porting
> over existing bookmarks. Frustratingly enough, though, doing anything
> meaningful with those is just out of reach. With no corresponding page
> context to run in, and no way to signal anything important before
> bringing up the popup in a manner programmatically indistinguishable
> from an ordinary click on the extension button (!), it would have no
> way of presenting any user interface.
>
> I've already had to hack around this strict behaviour to get the popup
> to be whatsoever conditional, but I believe that's the most I can do
> there. If there are any JS gurus reading who know some reason what I
> wrote might be wrong, please do let me know – I'd love to implement
> something like this if the extension APIs allowed me to.
>
> With the disappointing technical bits out of the way, some good news:
> page previews are actually incredibly easy to get from the tabs API,
> so some form of support for that would be doable. I'm mulling over
> ways to make favicon formatting more customisable. One potential
> solution is to just expose a snapshot of the whole tab data structure
> to both formatting functions and throw the user a link to MDN if they
> want to mess around. Another is to split the favicon title into its
> own formatting function, and evaluate it at slightly different points
> than where the current two are, so it could be intercepted when the
> popup is brought up.
>
> Either way, the addon is in quite a healthy state at the moment, and
> should get even handier and more flexible very soon.
>

-- 
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/2dd8c6ef-3ab5-428a-94bc-9106b7e3e1e2n%40googlegroups.com.

Re: [tw5] Announcing TiddlyMarker v0.1.0-alpha for Firefox

[amreus]

Yeston,

Thanks for creating this plugin - it's working very well so far. 

I would prefer to hide the bookmark tiddlers under a system prefix such as 
`$:/bookmark/` and use `window.location.href` as the unique identifier 
instead of using the the web page title as the tiddler title. 

Would it be possible to have a user-defined prefix or maybe a template for 
the tiddler titles? I would like to choose a prefix, including using a 
system ($:/) prefix when creating the title of the tiddlers.  One reason 
being that if 2 sites have the same title you can not bookmark both sites. 
This has already happened to me with only about 2 dozen site bookmarked. 




On Monday, June 8, 2020 at 2:57:24 AM UTC-4 Yestin Harrison wrote:

> Well, 0.3.0 is live on AMO. Besides fixing a rather nasty bug that
> rendered the popup inoperable under certain circumstances, I took it
> as an opportunity to make the download dialog opt-in (default off),
> and add an explanatory label to the server URL.
>
> As far as large features are concerned, there's one primary issue –
> there are rather strict requirements on what execution context can
> trigger the popup. This is ostensibly to protect users from surprising
> behaviour, but the long and of it is that as soon as I await something
> (such as making sure a tab is opened and then loaded, as would be the
> case for a context menu item to bookmark a link), I no longer have the
> ability to bring up the popup. That is to say, anything that depends
> on a resource that is not the current tab would have to either
> unconditionally run in “quick mode” with no ability for the user to
> edit anything, or instantiate some different mechanism within the page
> (i.e. port the popup to instantiate in a content script).
>
> The latter would work with some effort, but it has the unfortunate
> property that it would all be for *just* links. The lovely thing about
> the context menu API is that among its supported contexts are native
> browser bookmarks, which would be *incredibly* convenient for porting
> over existing bookmarks. Frustratingly enough, though, doing anything
> meaningful with those is just out of reach. With no corresponding page
> context to run in, and no way to signal anything important before
> bringing up the popup in a manner programmatically indistinguishable
> from an ordinary click on the extension button (!), it would have no
> way of presenting any user interface.
>
> I've already had to hack around this strict behaviour to get the popup
> to be whatsoever conditional, but I believe that's the most I can do
> there. If there are any JS gurus reading who know some reason what I
> wrote might be wrong, please do let me know – I'd love to implement
> something like this if the extension APIs allowed me to.
>
> With the disappointing technical bits out of the way, some good news:
> page previews are actually incredibly easy to get from the tabs API,
> so some form of support for that would be doable. I'm mulling over
> ways to make favicon formatting more customisable. One potential
> solution is to just expose a snapshot of the whole tab data structure
> to both formatting functions and throw the user a link to MDN if they
> want to mess around. Another is to split the favicon title into its
> own formatting function, and evaluate it at slightly different points
> than where the current two are, so it could be intercepted when the
> popup is brought up.
>
> Either way, the addon is in quite a healthy state at the moment, and
> should get even handier and more flexible very soon.
>

-- 
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/9e967760-d3d0-40cf-a686-d3d265efcaf0n%40googlegroups.com.

Re: [tw5] Announcing TiddlyMarker v0.1.0-alpha for Firefox

[Yestin Harrison]

Well, 0.3.0 is live on AMO. Besides fixing a rather nasty bug that
rendered the popup inoperable under certain circumstances, I took it
as an opportunity to make the download dialog opt-in (default off),
and add an explanatory label to the server URL.

As far as large features are concerned, there's one primary issue –
there are rather strict requirements on what execution context can
trigger the popup. This is ostensibly to protect users from surprising
behaviour, but the long and of it is that as soon as I await something
(such as making sure a tab is opened and then loaded, as would be the
case for a context menu item to bookmark a link), I no longer have the
ability to bring up the popup. That is to say, anything that depends
on a resource that is not the current tab would have to either
unconditionally run in “quick mode” with no ability for the user to
edit anything, or instantiate some different mechanism within the page
(i.e. port the popup to instantiate in a content script).

The latter would work with some effort, but it has the unfortunate
property that it would all be for *just* links. The lovely thing about
the context menu API is that among its supported contexts are native
browser bookmarks, which would be *incredibly* convenient for porting
over existing bookmarks. Frustratingly enough, though, doing anything
meaningful with those is just out of reach. With no corresponding page
context to run in, and no way to signal anything important before
bringing up the popup in a manner programmatically indistinguishable
from an ordinary click on the extension button (!), it would have no
way of presenting any user interface.

I've already had to hack around this strict behaviour to get the popup
to be whatsoever conditional, but I believe that's the most I can do
there. If there are any JS gurus reading who know some reason what I
wrote might be wrong, please do let me know – I'd love to implement
something like this if the extension APIs allowed me to.

With the disappointing technical bits out of the way, some good news:
page previews are actually incredibly easy to get from the tabs API,
so some form of support for that would be doable. I'm mulling over
ways to make favicon formatting more customisable. One potential
solution is to just expose a snapshot of the whole tab data structure
to both formatting functions and throw the user a link to MDN if they
want to mess around. Another is to split the favicon title into its
own formatting function, and evaluate it at slightly different points
than where the current two are, so it could be intercepted when the
popup is brought up.

Either way, the addon is in quite a healthy state at the moment, and
should get even handier and more flexible very soon.

-- 
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/CA%2BMGA5PSv%2BmaTHZ%2BrF8TpHk3Tkj8zEWGRowi%3DJmBQ-8mRaitGw%40mail.gmail.com.

Re: [tw5] Announcing TiddlyMarker v0.1.0-alpha for Firefox

[TonyM]

Yestin,

perhaps a field that contains the randomly named icon that can be overridden, 
perhaps click to name it domain/path.icon if I harvested the Facebook.com icon 
twice I would be happy to overwrite it rather than have two identical.

It may be a lot of work but I would love the same thing on a right-click on 
links.

Perhaps one day we could add a preview of the link to the tiddler.

Nice work
Tony

-- 
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/3db4bdcb-49f0-4f63-a085-0d02726bdc3co%40googlegroups.com.

Re: [tw5] Announcing TiddlyMarker v0.1.0-alpha for Firefox

[Yestin Harrison]

Mark,

> It's interesting, but seems to want only a traditional node connection, so 
> Bob and Tiddlyserver won't work.
I'm open to supporting these – As far as Bob is concerned, I've found
documentation and source code pertaining to API routes, which means I
could feasibly implement support. I've had no such luck poking through
TiddlyServer, but if someone were to point me to some docs, I could
make an attempt.
> It would be helpful if the form of the address was explained.
Good catch; that's an easy enough addition.
> After saving on node, the new item doesn't show up in the recent list until 
> you refresh the browser.
I'm afraid this appears to be a limitation of the API, as there
doesn't seem to be a call to push changes to clients. I find that in
5.1.22, the new “cloud button” -> “Get latest changes from the server”
is much smoother than hitting refresh.
> Getting rid of the "save dialog" would be a good enhancement.
I'll likely add a checkbox to this effect; luckily, this is quite an easy fix.

Tony,

> Could we also be allowed to provide a name for the icon?, basing it on the 
> domain name at a first step?
It would certainly be possible to add more parameters to favicon_fmt.
The rationale behind the current default is that a SHA-1 hash of the
icon data itself makes for an easy enough way of avoiding duplicates,
whereas depending on the site, different pages on the same domain can
easily feature different favicons. Are you envisioning an additional
field in the popup as well?
> Could there be a R-click tiddlymarker option to harvest from a link on the 
> page?
The current mechanism relies heavily on reading from a given tab using
the corresponding API
,
in particular as a foolproof way of obtaining the favicon, altogether
avoiding reading the page DOM. If I were to implement something like
this, it would likely open the link as a tab in the background and try
to read from it once loaded. It would be a bit janky, but I do like
the sound of that workflow.

Thanks for the feedback, both of you. The code is messy and overdue
for a refactor, especially with the most recent additions, but I'll
keep what's been said here in mind as I push for 0.3.0.

-- 
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/CA%2BMGA5OF7hOZNcwLhA%2BQC1Tjy7CzNXDrN9Hva%3DFY4UfCTNvp3Q%40mail.gmail.com.

Re: [tw5] Announcing TiddlyMarker v0.1.0-alpha for Firefox

[TonyM]

Yestin,

I have installed this and started playing with it. I think the 
documentation could be extended but it already seems quite powerful.

For others to read,

I went to facebook and clicked create bookmark, and it prompted to save 
Facebook.json, I dragged and dropped it on tiddlywiki.com and it imported 
the two tiddlers, one the icon the other the bookmark tiddler using the 
icon, the link field and a raw-title field. This works on online wikis as 
well.

Notes;

Its fantastic how it brings the icon with it, allowing us to harvest 
appropriate icons from the internet favicon.
One can update various things while doing this bookmark capture title text 
etc...


Questions;
Could we also be allowed to provide a name for the icon?, basing it on the 
domain name at a first step?
Could there be a R-click tiddlymarker option to harvest from a link on the 
page?
Note: I use the oneTab extension and often collapse open tabs into a list 
of links, a r-click would allow me to harvest these.

I am yet to work through its full functionality but it looks great.

Thanks
Tony


On Monday, June 8, 2020 at 6:13:33 AM UTC+10, Yestin Harrison wrote:
>
> I'm happy to report that Mozilla have approved the latest version of 
> TiddlyMarker for display on AMO. It should be much easier to install and 
> try out now at <
> https://addons.mozilla.org/en-US/firefox/addon/tiddlymarker/>. I can 
> confidently say I'm having a good time using it for my own purposes, and 
> I'm excited to see what others think.
>

-- 
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/882b9714-746d-4a44-9180-dc6e96a35cc1o%40googlegroups.com.

Re: [tw5] Announcing TiddlyMarker v0.1.0-alpha for Firefox

[Yestin Harrison]

I'm happy to report that Mozilla have approved the latest version of
TiddlyMarker for display on AMO. It should be much easier to install and
try out now at .
I can confidently say I'm having a good time using it for my own purposes,
and I'm excited to see what others think.

-- 
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/CA%2BMGA5P9fEGpYTPcAQ7x%3DmSycggWy%3D8r41tFCMOmvi_J7m74-Q%40mail.gmail.com.