On May 5, 2010, at 7:45 PM, John Nairn wrote: > My main reason to use SB is that is is there be default. I find that a > surprising (maybe) percentage of my users will balk at anything that requires > installation of something (even if free).
Yep, it's always nice when frequently used dependencies are included in the stock OS install (<koff>gcc, I'm looking at you), particularly in those environments (e.g. corporate) where the politics of third-party installs can be difficult to negotiate. That said, if folks are regularly using Python or Ruby in place of AppleScript, appscript's well worth a look simply because it's so much nicer to use than SB. Application scripting's painful enough without the extra headaches that SB brings, plus you get features like interactive help and ASTranslate to make the transition from AS that much easier. Alternatively, if the majority of your users are using Python/Ruby/ObjC, then you might want to consider forgoing Apple events altogether and providing a straight ObjC API, either via NSBundle-based plugins or via Distributed Objects. Not that these approaches don't have issues of their own, but at least they will provide users with a familiar OO API rather than the weird RPC+query idioms of Apple events (with or without SB's clumsy faux-OO semantics on top). > I think I know the reason the application commands do not work. It might even > be solvable, but in my app all commands at application level work at document > level too so that is a work around (because scripting without a document open > is not very useful) > > I think the reason is that the base application object in the scripting > definition is NSApplication and all my application commands are defined in a > category of NSApplication, but not in the object itself. I am guessing the SB > cannot handle that. SB does appear to generate the appropriate methods - albeit using a syntax that is neither consistent nor intuitive - but sdp is naming the methods differently when generating the corresponding header file (i.e. -commandName:nil argument:value vs. -commandNameArgument:value). Doesn't really surprise me - it's hardly the first time I've found SB and/or sdp to make a muck of things. Most of OS X's AppleScript-related technologies have been half-baked in concept and/or implementation, and their QA is completely lousy, so while it's frustrating this is nothing unusual by AppleScript standards. > A potential solution might be to subclass NSApplication in my app and then > define that class in the AppleScript suite. I'm very skeptical. It's not your application design that's at fault here; it's SB/sdp's doing, so trying to bend your app to suit SB will probably just backfire. As I say, SB makes all sorts of blind assumptions, so chances are that if you give your app an 'application' class by any other name it'll still work in AS (which is very forgiving) but will break even worse in SB. And don't forget that Cocoa Scripting can be very prickly too, so if the CS side is currently behaving itself then last thing you want to do is jinx that as well. If you know a significant proportion of your users will be using SB then I recommend you supply supplementary documentation that shows them how to write these commands correctly, also noting that sdp-generated headers define these method names incorrectly so that ObjC users will know to amend them accordingly. Regards, has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
