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.
