Solipsism Gradient

Posted by gracion:
AppleScript – good! Yes, I’ve used SuiteModeler for a couple of projects and it’s invaluable.

How about a “Save changes as AppleScript” command? After setting a creator, permissions, etc in one file, this would create an AppleScript that is ready to use on a batch. You’d have to track the changes of course (maybe as part of your undo module), but this might be very useful.

For example, Stone Software’s terrific Create page layout software has this kind of command – You can actualy save a document as an AppleScript. I think that’s more useful (and easier to implement) than recordability.

The other thing that’s important is to have a good object model – it takes some study to grok this area of script support, but think of the extra endorphin kick from learning all that

Yes, AppleScript can be very frustrating to write in. It’s really not one language, it’s N languages, where N = the number of AppleScriptable apps you use. I pretty much have to find sample code to get terms and syntax (especially coersions) right.

Leonardo Burci wrote:

you might also want to take a look at:

http://homepage.mac.com/donbriggs/

Thanks Leonardo, the #macsb folks also directed me to that page, and I’ll be checking it out.

Posted by Leonardo Burci:
Rainer,

you might also want to take a look at:

http://homepage.mac.com/donbriggs/

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.

OK, time to confess all. (cue ominous background music…)

You see, I have this congenital high activity monoamine oxidase A syndrome. In other words, I’m a neophile (also called “neophiliac”). One of the subtypes, at least… apparently I get an endorphine kick when I learn something new. Since you’re reading this, you may be one too! Very useful for a programmer, I must say…

Found at Media Life via Gizmodo.

We had a nice short vacation visiting friends in Campanha, in the interior of Minas Gerais, Brazil. This is a small town, almost equidistant from Rio de Janeiro, São Paulo and Belo Horizonte, and the main focus is coffee and tangerine plantations. I’ve posted 10 selected photos and maybe later I’ll post some more.

Meanwhile, I’m glad to report that XRay II is slowly getting back up to speed. I lost over 2 months doing premature optimization… yes, I should have known better, but it snuck up on me in the form of caching.

The file system browser in XRay 1.x was an afterthought, tacked on because I needed to check out many files to test. I used Apple’s SimpleBrowser sample code nearly as-is and only cached each item’s 16×16 icon. It worked amazingly well, but it didn’t react properly to events like volume mounting/unmounting and folders changing.

One of the first things I did for XRay II was to make a better browser. I also decided to use the same backend data structures for the browser and for the object that represented the file item being XRayed. Of course this meant that the icon had to be cached in each object, as well as the name, the FSRef, the pointer to the parent folder… then I thought, I’d also better cache catalog info results, metadata, etc. etc., as all this would be needed later. Soon this object grew like topsy, adding all sorts of interesting information about the file item, each added lazily whenever requested…

…but it turns out that it became increasingly complex to keep this back-end cache synchronized with the actual file system. In fact, everything I did to optimize the cache internally made it more difficult to do external synchronization.

So, over the last month I basically started out from scratch with the back-end and, as soon as possible, implemented mount/unmount modifications, and folder change notifications (using M. Uli Kusterer‘s excellent UKKQueue). It turns out that it’s basically unproductive to cache anything but the name and icon… except, of course, while an item is being XRayed.

More as it happens…

Yes, we have progress. We’re taking a few days off, visiting friends, to commemorate… expect a post on the evils of premature optimization when we get back on Sunday.

Keola Donaghy wrote:

Hau’oli la hanau ia ‘oe!

Mahalo a nui loa!