Now that XRay II’s file browser is working reasonably – some edge cases excepted – it’s time to refactor the GUI, and to worry about how this will affect the internal architecture.

I had an excellent discussion yesterday on #macsb about the possibility of adding AppleScript support. My interest about this was renewed by Daniel Jalkut’s discussion of adding minimal scriptability to a Cocoa application. Seems that the AppKit already has such support built-in, and you get it for free by turning on one option in the app’s .plist file. Daniel gave me some very good suggestions on #macsb, and I’m seriously investigating the possibilities at this time…

My previous experiences with AppleScript were not very good. The syntax itself is confusingly English-like: it sorta kinda looks like English – and verbs and whatever are chosen to make it even more so – but there’s no flexibility at all. The few times I had to write (or change) a portion of AppleScript took me hours with the manual opened in one window and the editor in another.

When I wrote the Aurélio Eletrônico – a Portuguese dictionary app – waay back in the Mac OS 8 days, at one point someone convinced me to build in AppleScript support. At the time, this was done by CodeWarrior’s PowerPlant classes and I seem to remember that most of it actually worked. However, I never got around to documenting what exactly had been implemented, and to the best of my knowledge, no user ever needed it for anything.

Adding scripting to XRay II would have advantages and disadvantages. My original plan was to pitch it as an exploratory sort of utility… a way to look closer into the innards of files and bundles, and to find out their structure. And, eventually, to edit some small part here and there. However, it seems that there’s serious demand to do batch processing; people want to add filetypes to all .mov files inside a certain folder, etc. Or, once a certain tweak to a file has been done, this tweak must be repeated periodically – from inside an Xcode build phase, for instance.

Allowing such functionality would of course expand XRay II’s uses enormously, but it also would make the responsibility much greater. It’s easy to completely bork up the system by running a buggy script, much more so if the scripted app can run with privileges. The internal structure would also be changed. I’d have to be more canonical in implementing the Model-View-Controller pattern and be careful to separate the user interface from actions on data; something I’ve been known to sacrifice, sometimes, for efficiency and code compactness.

At any rate, this offers an opportunity to learn something new, and to make XRay II even more powerful. Stay tuned for more news about this.