> The way things are now, each browser plug-in provides a catalog preset for bookmarks. If all your bookmarks are > synchronized, you could just uncheck all but one.
Agreed. I don't think there should be a single browser plugin. That might get messy, too bloated, and if you didn't want a plugin for all browsers then it'd be a bit fiddly. Unchecking catalog items is the way to go IMO. > We could either append something to the label, so you’d have “Current Web Page (Safari)”, “Current Web Page (Chrome)”, > etc. or we could make the label identical for all of them and differentiate them using the icon and the details (the second > line you sometimes see under the label). I like the idea of just using the application in question's Icon, like it is for the Safari proxy. Adding a label may be a good idea, but it won't show in all interfaces. I agree, small fixes to the plugins so it doesn't look like they're dormant (and it'd also help us update any .xccodeproj files) On 16 April 2011 04:34, Rob McBroom <[email protected]> wrote: > On Apr 14, 2011, at 5:17 PM, Henning Jungkurth wrote: > > > - 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 way things are now, each browser plug-in provides a catalog preset for > bookmarks. If all your bookmarks are synchronized, you could just uncheck > all but one. > > > - 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? > > Before I go further, note that there has never been something like “Current > Web Page” for Firefox. Only for Safari and OmniWeb. They use AppleScript, > which doesn’t appear to be an option with Firefox. I won’t say it’s > impossible though. If Firefox is writing history in real-time as you browse > and you could figure out how to parse it, you could get the “last viewed” > page, which is close (but there’d be no way to tell if it was actually up at > the moment). A lot of people would probably be happy if you figure it out. > > It should be possible to ask the OS for the bundle ID of the default > browser. That’s probably the one to use if you’re trying to be “smart”. But > then how do you translate that to a plug-in? Even if we moved “Current Web > Page” into the core application, I don’t think it should know how to talk to > every browser, so it would have to hand the work off to a plug-in somehow. > That might be possible, but then what if you want the current page from a > non-default browser? Perhaps the “Current Web Page” proxy could have > children (when you right arrow into it) for all browsers that support it. > > Here’s my suggestion: We standardize on a name (“Current Web Page” or > “Current URL”) for this proxy object in all browser plug-ins. We could > either append something to the label, so you’d have “Current Web Page > (Safari)”, “Current Web Page (Chrome)”, etc. or we could make the label > identical for all of them and differentiate them using the icon and the > details (the second line you sometimes see under the label). > > If there’s one you prefer and use more often, Quicksilver will learn this > and it will become a de facto default. And because the names are so similar, > if you do want a different one now and then, they should all appear just > below in the results. > > This doesn’t require users to somehow discover that they can right-arrow > into it to see alternatives and it doesn’t require Quicksilver to make any > assumptions about which browser you meant. > > And finally, this can be implemented today with some small alterations the > plug-ins*. We wouldn’t have to restructure anything in the core application. > I was going to make a small tweak to the OmniWeb plug-in anyway. Might as > well do this. > > Thoughts? > > * As far as I can tell, it isn’t currently possible to set the details on a > proxy object from the plug-in, but the icon can be changed. > > > - 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. > > I think those actions are more akin to opening URLs, which the OS already > knows how to handle. The mail application equivalent of what we’re talking > about would be more like reading in contacts and mailboxes. > > -- > Rob McBroom > <http://www.skurfer.com/> > >
