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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CA%2BMGA5PSv%2BmaTHZ%2BrF8TpHk3Tkj8zEWGRowi%3DJmBQ-8mRaitGw%40mail.gmail.com.
