486 words
I've learned a bit more about how to add scripting information to your application since my post last weekend. It turns out that those mysterious sdef
files are supposedly the future of that very task.
Introducing this file format is then probably what people call a 'long term strategy' by Apple. Allegedly its manpage was written more than two years ago and yet the system still doesn't support the file format directly – you're required to run it through the sdp tool manually to create old fashioned Cocoa style script*
files or even more old fashioned aete resources. XCode won't figure this out for you – which may be related to the fact that the different approaches to advertising your scripting capabilities aren't fully equivalent.
So far so funny. While the new file format unifies both the files used in the traditional Cocoa picture (and doesn't seem to support the InverseRelationships property they had in those – whatever these did), it is yet another file format. 'Generic' XML for a change, no property list. Which of course means there is no comfortable way of editing these, not even the half-assed PropertyList Editor. So get out your text editors...
... and see that any non-trivial incarnation of XML is just butt ugly and highly redundant (to the human reader). And it's easy to get lost in there. To prevent the latter at least, I saw that I could quickly augment Hydra's XML mode to at least represent the structure of the file neatly in its function popup menu. That wasn't fun but at least reasonably easy. If you also want to edit sdef files, you can use my – probably imperfect - sdef.mode for assistance.
I also tried adding autocompletions of all relevant tags to that mode. But that failed for two reasons. To begin with SEE's autocompletion feature doesn't work if you're using TextExtras. And even without those, the system's standard way of doing completion won't recognise typical XML tags like </property&rt;
as a word but will insist a new word starts after the angle bracket. This makes everything much less useful. But to the best of my knowledge some extra programming will be required to change this.
And, yes, as the screenshot suggests, my scripting efforts have been going into making the useful Bibdesk application scriptable. While things aren't ready for prime time yet, they look very promising. AppleScript can be very powerful for even for lower level tasks. Notably it takes the pain out of doing interapplication communication (even if this isn't as hard to day as it was in the days of the PPCToolbox, it's still scary enough) – albeit at a little speed hit.
Things I managed to do with this so far (and unfinishedly) are integration with LaunchBar (as outlined a while ago) and autocompletion for TeXShop.
Despite the odd annoyance or ten, I'm starting to like this.It’s a Java application, and, hence, a little unpleasant to work with in those ways that Java apps tend to be, but I’ve found jEdit’s (http://jedit.sourceforge.net/) XML support to be rather robust. It’s my editor of choice when running FreeBSD or Linux or when stuck on a Windows box.
Yikes, ugly.
I didn’t see any specific XML support apart from syntax highlighting at first sight.
I was thinking more along the lines of a truely graphical editor that lets you see the hierarchy, rearrange and duplicate complete structures and so on. Kind of a fleshed out Property List Editor.
IIRC, you have to install it as a plugin (jEdit’s plugin manager is excellent — fetches a list of available plugins with descriptions, then allows you to install the ones you need by ticking a checklist)
I haven’t used this program, but I’ve heard good things about it. It’s got an on-the-fly validator, among other things.
Haha, a text editor with a plugin manager. Sounds wrong.
I tried it anyway, but it couldn’t contact its server or something.