Re: building an AppleScript editor app
Re: building an AppleScript editor app
- Subject: Re: building an AppleScript editor app
- From: has <email@hidden>
- Date: Sun, 07 Dec 2014 16:31:38 +0000
sqwarqDev wrote:
> As the title suggests, I'm building an AppleScript editor
(Objective-C, not Swift). I've got reasonably far replicating the
abilities of the in-built Script editor and have even added a few bells
and whistles. However, I'm stuck, conceptually, on one particular hump.
IMO you're almost certainly wasting your time. The aged AppleScript
market is moribund, and the nascent JavaScript for Automation market is
stymied by JXA being a total sack of crap.
OSA is built upon the Carbon Component Manager, which was deprecated in
10.8. The Carbon OSA (OpenScripting) framework has been a legacy API
since 10.6, and some functions also require deprecated types such as
FSRef in addition to Component/ComponentInstance. OSAKit framework is
supposed to be a Cocoa alternative, but is an undocumented sack of crap,
and you still have to drop down to the Carbon OSA APIs for the sorts of
non-trivial operations an OSA editor requires.
> When a script in my editor returns a record that contains the
four-letter codes defined in the target application's dictionary, what
is the best way to translate the code back into human readable form for
display in the results window?
You don't. You use the OSA to do it for you. OSAExecute and friends
return an OSAID for a newly created ScriptValue object containing the
raw result. You pass that ID to something like OSADisplay if you want
that result as a display string, or to OSACoerceToDesc if you want it as
an AEDesc. It's quite tedious, but it works. Or you use OSAScript, which
has a very stupid method that returns both a display string and an
AEDesc at the same time.
> I haven't yet got round to building my XML parser for my Dictionary
viewer (that's next up), so I don't know if there are some methods that
might help me in NSXML (a brief look over the class didn't suggest
anything useful), but I'm imagining that I'm going to have to do
something like this:
>
> i. load the applications dictionary into my code
> --> (I'm assuming I do this with an NSTask calling sdef...any other
suggestions?)
OSACopyScriptingDefinitionFromURL() is busted: documentation says both
file: and eppc: URLs are accepted, but file: URLs return garbage
(specifically, an SDEF for AEM's degenerate XML-RPC/SOAP support).
OSACopyScriptingDefinition() requires an FSRef, which in turn requires
use of deprecated functions like CFURLGetFSRef(). Honestly, calling out
to `sdef` is probably the least horrid option.
> ii. parse the AEDescriptor result for the four-letter codes
> --> (currently, my thinking here is to turn the whole result into an
NSString and use an NSScanner)
Wut? Or are you still talking about displaying the script's return
value? If so, stop shoveling and see above.
As to dictionary viewers in general: OSAKit contains the dictionary
viewer classes used by SE, though needless to say it doesn't work right,
particularly when displaying inheritance and containment graphs which it
almost invariably mucks up. I wrote some thoroughly horrible code for
ASDictionary that does a much better job, although I don't think I ever
finished the SDEF parser as the AS team keep mucking with the format and
SDEF's always had bugs. Public domain code can be found in the old
appscript svn repo. Either way, you deal with crap, insanity, or both.
And you'll be pretty much on your own all the way: after a few thousand
hours down the toilet I no longer provide any public appscript support
(so if you want specifics you'll have to pay consultant rates), and good
luck trying to get help out of any of the current AppleScript engineers
(not that they understand half this stuff right anyway).
As to general advice: I suggest you find yourself the original Inside
Macintosh sections on Apple Event Manager and Scripting Components and
read those to get some idea of how OSA works. (Be aware that even these
are horribly light on specifics.) Also William Cook's HOPL paper on the
early history of AppleScript is useful background. The JavaScriptOSA
component I wrote after WWDC14 so the JXA devs could use it as reference
(they didn't) is available at
<http://sourceforge.net/projects/appscript/files/>. Again, unsupported,
unfinished, and not 100% right (the more obscure, advanced behaviors I
was semi-guessing due to lack of public Apple documentation), but it may
provide some insight into how OSA is designed to operate. (I did
actually start writing an OSAKit replacement as well, but a brief bout
of sanity cured me in time.)
Bear in mind too that OSA and the AS component are twenty year-old tech,
and hopelessly obsolete by modern standards. There's no support for
incremental parsing, for example, which you need to support stuff like
dynamic code coloring and auto-complete which modern scripters expect.
There's no hooks for debuggers or profilers, which users also expect,
and you will probably go insane trying to hack your own workaround. The
only person who's ever managed is Mark Aldritt, and I doubt he'll want
to share his secrets. So be prepared to invest a very large number of
hours figuring all this crap out (e.g. appscript sucked up a couple
thousand to get 99% right, and it was just an AE bridge), and still have
a poor product at the end of it.
Honestly, you'd be better off building your own (non-OSA-based) language
from scratch, then writing an editor around that. It'll be quicker and
easier, and while you still probably won't get any customers for it at
least you'll hate yourself less afterwards. (You don't think I got this
nuts by accident, do you?)
Regards,
has
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden