I was just thinking about revamping the Firefox plugin. You know,
reading directly from the sqlite db. :-)
I like your idea about combining certain browser stuff. Just some
random thoughts:
- It'd definitely need some mechanism to eliminate duplicates. Many
people who use several browsers sync the bookmarks between them. So
having the same bookmark three times in QS, from Safari, from Firefox,
and from Chrome would be very annoying.
- The "Current Web Page" could of course be combined too. But if
you're using two (or more) browsers at the same time, which current
web page would be used? The one from Safari or the one from Firefox. I
would guess the one from the most recently used browser. Or maybe the
one from the more frequently used browser?
- For email-handling in QS there is a mediator (QSMailMediator), that
handles the common email actions ("Email Item...", "Email to..."...).
That might be a good place to start looking for ideas on how to design
that.
On Thu, Apr 14, 2011 at 10:18 PM, Eric Doughty-Papassideris
<[email protected]> wrote:
> Hi all, this talk of getting a chrome plugin in reminds me that the
> firefox plugin is broken but discretely so (it parses bookmarks.htm
> which is only up to date if you use a special about:config style
> setting in firefox, bookmarks and the like moved to an sqlite store at
> some point).
> This, with the added confusion of "Current Web Page" meaning Safari's
> and so make me wonder wether browsers, being such an ominous tool,
> shouldn't be better handled, as in, have one "agnostic" browser plugin
> that adds current web page and so one, and a mediator system for
> picking what that means. This would allow for one Bookmarks catalog
> entry that indexes all the browsers present for example, and would
> normalise how QS and browsers interact.
> Now (as in Chrome and Firefox and Opera plugins lagging behind) might
> be a good time to think about this. Any suggestions on how to
> structure that ?
> I use most browsers interchangeably, I really haven't settled for any,
> so I realise my use case might be uncommon, or is it ?
>
> Best Regards,
> Eric Doughty-Papassideris
>
>
>
> On 14 April 2011 19:12, Ian Hay <[email protected]> wrote:
>> I use the sync feature and there is still a Bookmark file where Patrick said
>> his was, doesn't mean there isn't something else though since I didn't
>> always use the sync feature !!
>>
>> -ian
>>
>> On 14 Apr 2011, at 16:23, Rob McBroom wrote:
>>
>>> On Apr 14, 2011, at 11:06 AM, Patrick Robertson wrote:
>>>
>>>> Looks like the Chrome Bookmarks are stored in a .json file, which means
>>>> the plugin would just need to open up the file (App
>>>> Support/Google/Chrome/Default/Bookmarks for me) use a .json parser (I use
>>>> JSON Framework in my 1Password plugin) then make them URLs.
>>>
>>>
>>> Notes for the mythical Google Chrome Plug-in developer:
>>>
>>> I was thinking a proper browser plug-in would also provide access to
>>> history and a proxy object referring to “the URL of the page I’m currently
>>> looking at”. Looking at the AppleScript support in Chrome to see if the
>>> proxy object would be possible (I think it would), I noticed some
>>> references to “bookmark item”.
>>>
>>> On the one hand, it might be safer to get a list of bookmarks via
>>> AppleScript, so if the internal format ever changes, it still works. On the
>>> other hand, that only works if Chrome is running, which is not ideal.
>>> Personally, I think it’s worth the risk to go to the JSON file directly.
>>>
>>> Anyone know what happens if you use the service that syncs bookmarks?
>>> Things to check for would be:
>>>
>>> 1. Does the browser still store them locally at all, or does it just rely
>>> on the remote info?
>>> 2. Does it still use “Default”, or does it create a new folder based on
>>> your Google Account?
>>>
>>> Have fun, mythical developer! :)
>>>
>>> --
>>> Rob McBroom
>>> <http://www.skurfer.com/>
>>>
>>
>>
>
