Right now, AS support is inferior to Communicator's, which was never more than a browser dictionary anyway. By adding AS support for all tasks within Moz, including email, news and web composition/viewing, it would allow Mac based workflow apps to have a choice other than Outlook Express or Eudora. It would also give those who need to have both the browser and email scriptable the ability to do just that. Considering the adaptability of scriptable apps, this would greatly increase Mozilla's adaptation rate by the Mac community. An example of how this is useful would be for a multimedia web flow. By linking a fully scriptable Mozilla to Photoshop, with the Photscripter plugin or Graphic Converter 4.0, and an image database such as Cumulus, you could have a client send you via email a stuffed set of high resolution images. A filter would note the sending address, and remove the attachment, placing it in an open folder. A folder action would then unstuff the images, and insert them into cumulus. It would also take one of those images, and pass it to a Photoshop/Graphic converter script, which would convert it to a jpeg, and downconvert the resolution to 72 or 96 dpi. THe script could then send this sample back to the client for approval by building a new email message in Mozilla and attaching the image. The client then sends it back with approve/disapprove in the header. If disapprove, the email is forwarded as an attachment to the appropriate person. If approved, *another* script is started which batch converts all the images, and then inserts them into a web page, in either composer or another web design product, and the approve/disapprove cycle could repeat. Once this is done, then the final page and images are pushed out to the appropriate server, and the time taken is dumped into a FMPro database, where an invoice is generated. All of this can be done *now* using IE or Communicator as a browser, and OE/Entourage/Eudora for email, and BBEdit/Dreamweaver/AS native/ GoLive as the HTML generator. If Mozilla were to adapt the capabilities of these other application's dictionaries, and implement them into it's own, then the workflows could be *greatly* simplified by going to one product for email/html viewing/creation. This would make Mozilla a VERY attractive product in AS workflows where email, HTML functions, etc. are used. John Welch mactech, macweek, and IS AppleScript wizard
over to email@example.com
*** This bug has been marked as a duplicate of 5701 ***
Reopening as a request for more advanced Mac OS scripting support via OSA than required in the basic required suite.
Sure, I'll get right to it ;)
Also add a Script menu to the menu bar... will make locating and launching Mozilla AppleScripts more convenient.
If this is about XPConnect/OSA, then it probably belongs on the XPConnect component rather than General. Leaving with sfraser, though.
I actually started to work on this for a while. The way Apple Events are reflected into a Cocoa appication, using key-value coding on objects, made me think that I could write some kind of DOM object proxy class in Obj-C that implements handleQueryWithUnboundKey:key, mangle that key into the name of a getter method, and call through XPConnect an interface method on the node the proxy object wraps. Of course, to allow people to write Apple Scripts to get at DOM content, you also need a scripting dictionary for all the DOM stuff. That kinda works, but there is enough of a mismatch between the DOM APIs and the way that key-value coding works that things quickly break down. Accessing child lists, and child nodes by index is an obvious example. So, I think the way to go here is to just write Obj-C wrapper classes for the various DOM and HTML interfaces, and build up a big scripting dictionary. This wouldn't be too hard; it's just tedious. Maybe some could even be automated by hacking on the idl compiler.
Does GUI Scripting http://www.apple.com/applescript/GUI/ handle make this unnecessary?
GUI Scripting does not even come close to resolving this issue. GUI Scripting is a barely acceptable way of mimicking a user's manipulation of the mouse and keyboard. Real scripting allows communication with a program whereby one can get values, set values, perform actions, and more - often without any visible action in the interface. Can you imagine if system maintenance tasks started writing commands on the command-line you were working on? Or, if you have a time-server, if you had to watch an application launch, show a progress bar as it asked for the current time, open your Date/Time control panel, and pasted in a value? That is not scripting - that is running a macro, which is VERY different. GUI Scripting is a horrible kuldge for poorly-written applications.
This is a mass change. Every comment has "assigned-to-new" in it. I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Note that Tom Dyas has some code that might be useful in bug 516502.
bug 608049 made good progress towards adding AppleScript support for Firefox. It would be great if at least the basics of that could be pulled over to Thunderbird. In particular the ability to get the current email URL like Postbox already supports. This is needed for linking in productivity apps like Things and OmniFocus.