User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060214 Camino/1.0 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060214 Camino/1.0 It would be excellent if Camino had Automator actions available as Safari does. A few examples actions from Safari are: - get image URLs (input: URLs, output: URLs) - get link URLs (input: URLs, output: URLs) - get current web page (requires: a web page open in browser, output: URL) - get text of web page (input: URL, output: text) Some other actions might include: - get rss feed from web page (input: URL, output: text) while this can be done currently by giving an action the URL of the feed, this action would work differently in that you could give it the URL http://www.apple.com and get the associated RSS feed based on the >link rel="alternate" type="application/rss+xml" title="RSS" href="http://wdirect.apple.com/home/2006/ticker.rss"< tag in the header. - bookmark related actions I can't think of anything specific right now, but that is something that's missing from Safari's actions. Perhaps an action that would return the URLs of a given bookmark folder to be used in following actions Camino is billed as the OS X "tied in" version of Mozilla. It's excellent! Having an alternative to an occasionally buggy Safari. Now it would seem that it's time to start adding in more OS integration, thereby making the product more attractive to a wider audience. Reproducible: Always

See also bug 293322. Personally, I'd prefer we implement smfr's plans for improved AppleScript support (bug 314061, bug 178917, bug 156078, bug 160106).

I agree... depending on the intended audience for this application. The question for the developers is: "Who's the audience for Camino?" If the target audience is other developers and programmers then I can absolutely get behind working on AppleScript first. However, if the target audience is a more inclusive set of desktop users then I would say Automator should come first. I know that the majority of Mac users are reasonably handy with AppleScript, but Apple's been picking up small pieces of market share lately and the switching crowd is in part switching because of features like Automator. I'm not claiming that's the sole reason, but it's technologies like it that are beginning to make a difference. I'll wrap up by saying, sorry about the dup. I hunted for "Automator" related bugs yesterday before I posted this feature request and came up with no results. ...I only searched under Camino bugs. *** This bug has been marked as a duplicate of 293322 ***

Reopening. This would be implemented above the level where Camino and Firefox share code, so it's not a dup.

If we're going to implement this (and I agree we should), we're going to need to decide on a clear set of actions to implement. In my AppleScript proposal it made sense to simply model Bookmarks (for instance) and expose their relevant properties. Automator is a different paradigm. It's non-obvious what should be an action and what shouldn't. Jamie's suggestions are great; let's talk through it and make some firm decisions. Perhaps this needs a live scoping meeting?

(In reply to bug 284554 comment #25) > (In reply to comment #20) > > (In reply to comment #8) > > > BTW, do we link against AppleScriptKit.framework? > > > We may need to do that too. Or it may be enough to let the prefPanes do that. > > > > Linking against that framework doesn't seem to fix the problem. > > In the event we ever come back to this bug and try to figure out how to make > it work, dcj points out linking ASK is bad news: > http://openradar.appspot.com/radar?id=232401 And Automator.framework brings in ASK (though, from dcj's OpenRadar: "also rare to link to Automator").