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.
