If all goes well, this will be the first time I've posted something using my tools that I've been able to set an explicit Department for the news item.

A point about how Departments are implemented in Manila. Each news item can be assigned to a Department (for instance, this news item is in the Scripting Department). A site editor can define the categories that can be used and assign them unique images. Unfortunately, the only thing I've found in the Manila RPC that addresses Departments is the ability to set the Department for a news item using a string. There's no way to get a valid list of departments for a given site.

That's a shame. I'd love to have a drop-down menu that allows the user to choose the department. As it stands I'll probably have to have the user type it in.

A follow-up to my earlier item about using secure text fields: Apple's mailing list comes through again. Tim Bumgarner, the tech lead on Applescript Studio, emailed me to point out that I could address the secure text field as a regular text field instead since the secure text field class inherits from the regular text field class.

What I find interesting about this is that it points up some interesting philosophical differences between Applescript Studio and other environments I've programmed in. Here, to address a control or other user interface element, you need to specify the control by class, for instance

get contents of text field "userPassword" of theWindow

Note the quotation marks around the text field name? The control's names are not bound at compile time but are interpreted--good and bad; you can pass the name in as a string variable but you don't get any protection from the compiler if you make typos.

I've been digging for a while on Manila Envelope, getting frustrated by a few things. Still impossible to work with secure text fields in AppleScript Studio. However, I now have the application working with a preferences file. This is pretty critical, as this was the last missing piece of functionality to make Manila Envelope do everything that my old scripts did.

My original goal was to make this release an "everything and the kitchen sink" one, and add in lots of stuff like style translation and so on. I think, though, that it's time to avoid the Mozilla syndrome and fix on a reasonable set of requirements for 1.0. With this, I can hopefully release 1.0 in the next few days, before I go on my January road trip.