31
edits
Mac:AppleScript: Difference between revisions
→Current Plan
m (→Current Plan) |
|||
| Line 21: | Line 21: | ||
The bug for improved AppleScript support in Gecko is {{bug|61356}}. | The bug for improved AppleScript support in Gecko is {{bug|61356}}. | ||
The bug for improved | The bug for improved AppleScript support in Firefox is {{bug|61356}}. | ||
Other bugs for | Other bugs for AppleScript in include: {{nbug|125419}}, {{nbug|156078}} (Camino), {{nbug|237733}}. | ||
The ideal solution is to allow Gecko applications to dynamically register for | The ideal solution is to allow Gecko applications to dynamically register for AppleScript commands which are then forwarded to them, without the caller needing to write their own Objective-C. | ||
e.g. if Firefox Sync would like to have an | e.g. if Firefox Sync would like to have an AppleScript command "tell application "Firefox" to sync", it could register with the AppleScript service to forward all "sync" AppleScript requests to their Javascript code. | ||
The current plan is to create a solution tailored for Firefox, which could be replaced by a more generic solution (once one is found). | The current plan is to create a solution tailored for Firefox, which could be replaced by a more generic solution (once one is found). | ||
| Line 33: | Line 33: | ||
'''Generic Solution Proposals''' | '''Generic Solution Proposals''' | ||
*Proxy objects: similar to Tom Dyas' work in {{bug|516502}}, have an application create their own set of proxy Obj-C classes to respond to | *Proxy objects: similar to Tom Dyas' work in {{bug|516502}}, have an application create their own set of proxy Obj-C classes to respond to AppleScript. | ||
**Pros: native Obj-C solution, less chance of problems interacting with Apple's code | **Pros: native Obj-C solution, less chance of problems interacting with Apple's code | ||
**Cons: must regularly update proxy objects, may not represent actual state of application. Also, much be maintained on a per-application basis (not within Gecko) | **Cons: must regularly update proxy objects, may not represent actual state of application. Also, much be maintained on a per-application basis (not within Gecko) | ||
*Catching requests: override KVC and preformSelector on NSApplication subclass to catch requests from | *Catching requests: override KVC and preformSelector on NSApplication subclass to catch requests from AppleScript and forward requests to other classes that register with an AppleScript service | ||
**Pros: can be maintained at the Gecko-level, allows developers with no knowledge of Obj-C to provide functionality to | **Pros: can be maintained at the Gecko-level, allows developers with no knowledge of Obj-C to provide functionality to AppleScript | ||
**Cons: could have performance implications (given changes to NSApplication), greater chance of problems interacting with Apple's code | **Cons: could have performance implications (given changes to NSApplication), greater chance of problems interacting with Apple's code | ||
*Override [NSScriptCommand executeCommand] and do our own parsing and handling of | *Override [NSScriptCommand executeCommand] and do our own parsing and handling of AppleScript commands. | ||
*Provide a basic level of commands at the Gecko level which return results based on Javascript queries (e.g. a request for application->window->tabs would use Objective-C objects for application, windows and then use Javascript to find the current tabs and fabricate Objective-C objects that reflect their current state.) | *Provide a basic level of commands at the Gecko level which return results based on Javascript queries (e.g. a request for application->window->tabs would use Objective-C objects for application, windows and then use Javascript to find the current tabs and fabricate Objective-C objects that reflect their current state.) | ||