Fluid 0.8.6 Released with Plug-in API and more JS API
With 0.8.6, I’ve finally released the Cocoa Plug-in API for Fluid! Unfortunately, I’ve only released one very simple Plug-in for now: the Clipboard Plug-in. I doubt anyone will be blown away by this particular Plug-in… but the other Plug-in I’m working on has been holding me up for weeks now, so I figured it’s better to just get the API out there.
However, I’m hoping the Clipboard Plug-in will get developers excited about the possibilities when developing Cocoa UI plug-ins for a WebKit-based browser/SSB. The really great thing about Fluid’s Plug-in API is that your plug-in can appear in multiple places in the UI. As the developer, you get to decide which places are allowed for your plug-in, and the user can choose her preferrred placement from the allowed placements in the Preferences window.
To help devs along, I’ve released the source code to the Clipboard Plug-in as an example.
Also in this release is lots of JavaScript API for Userscripters. See the changelog below.
- FluidInstance.app: Plug-In API!
- FluidInstance.app: Clipboard Plug-In.
- FluidInstance.app: “Photo Browser” added for iPhoto-like image browsing. Main Menu -> View -> Photo Browser (control-option-command-b)
- FluidInstance.app: Preference to “Open new links from other Applications” in new tab or new window.
- FluidInstance.app: “Create TinyURL” from context menu when you right click a link.
- FluidInstance.app: “New Userscript” menu item creates a new Userscript template, places it in this SSB’s Userscripts dir, activates it, and opens it in your default text editor.
- FluidInstance.app: JS API: fluid.dockBadge = “foo” - The dockBadge feature is now exposed as a read/write property of the fluid object, rather than a method. The method is deprecated, but will probably remain.
- FluidInstance.app: JS API: fluid.hide() - Hide this SSB application. Available only to local Userscripts.
- FluidInstance.app: JS API: fluid.unhide() - Unhide this SSB application. Available only to local Userscripts.
- FluidInstance.app: JS API: fluid.activate() - Bring this SSB application to the front. Available only to local Userscripts.
- FluidInstance.app: JS API: fluid.terminate() - Quit this SSB application. Available only to local Userscripts.
- FluidInstance.app: JS API: fluid.include(pathStr) - Eval a local JavaScript file located at the given path. Available only to local Userscripts.
- FluidInstance.app: JS API: fluid.applicationPath - a string path to this SSB’s .app bundle directory (“/path/to/MySSB.app/”). Available only to local Userscripts.
- FluidInstance.app: JS API: fluid.resourcePath - a string path to this SSB’s Resources directory (“/path/to/MySSB.app/Contents/Resources/”). Available only to local Userscripts.
- FluidInstance.app: JS API: fluid.userscriptPath - a string path to this SSB’s Userscripts (“/Users/Mandy/Library/Application\ Support/Fluid/SSB/Campfire/Userscripts”) directory. Available only to local Userscripts.
- FluidInstance.app: JS API: fluid.log(obj) - This method is now only available from Userscripts.
April 4th, 2008 at 04:37 am
Hello,
Great news but the .fluidplugin isn’t associated with fluid after I updated using Sparkle. So I drop the plugin into the Lib/App Support/Fluid/PlugIns. But now I have only the Plugins menu in my Google Reader SSB. Not in the other. Any idea?
April 4th, 2008 at 12:37 pm
Todd, what does the below snippet mean? Is this for setting Fluid as your default browser and controller it’s behavior? Is there a way to say “catch all muxtape.com url’s and send them to the muxtape Fluid app”?
* FluidInstance.app: Preference to “Open new links from other Applications” in new tab or new window.
April 4th, 2008 at 13:54 pm
@Mickaël for the .fluidplugin files to be associated correctly with Fluid, u have to update Fluid.app itself first. Updating just an SSB will not create the association. Also u must update each individual SSB to version 0.8.6 before u will see the plugin features appear in each SSB. Alternatively u can delete the SSBs and recreate them using Fluid.app 0.8.6.
April 4th, 2008 at 13:56 pm
@Josh Owens yes that is correct, that setting is for u if u have set a Fluid SSB as yr default web browser. Currently there is no way to register an SSB as the handler for certain URLs across the system. I’d like to add that in the future, but it won’t be easy.
April 4th, 2008 at 15:32 pm
Ok I see, the Check For Updates menu of the SSB is a bit disturbing. A feature to update all the SSBs in one time will be useful?
April 4th, 2008 at 16:13 pm
@Michaël dusturbing? If it weren’t for that feature, then you’d have to delete and recreate each SSB after every
time you updated Fluid.app to a new version. That would not be cool.
April 5th, 2008 at 03:47 am
Sure, it’s useful. But while I updated just Google Reader, I thought I was updating all the SSBs and Fluid. But maybe I’m alone in this case.
(By disturbing I mean misleading. Sorry I’m not english and I thought disturbing means misleading.)
April 5th, 2008 at 09:58 am
@Michaël if you think about it though, what you’re asking for isn’t really feasible. Fluid would have to track where you move every single SSB you ever created on your system… There’s no way for Fluid to know where you drag an SSB after you create it.
Alternatively, Fluid could attempt to store the “guts” (executable) of all the SSBs in one central location so that it could update all at once. Even if that were possible (not sure that it is) you would loose any ability to move the SSB to another system that doesn’t have Fluid installed, which many users seem to like to do.
Sparkle update for each SSB is actually quite a nice solution as it is a relatively painless two click update for each SSB.
May 16th, 2008 at 10:11 am
Hello my friends
