Jarrett House North

One additional thing about Manila Envelope — it’s a little bit of a paradigm shift from my scripts. I think the change is for the better.

With TextEdit2Blog, I started out trying to write a universal “save to the Web” script menu item for all text applications. The script was supposed to grab the selected text from the frontmost application and post it to the web. I soon realized that this just wasn’t feasible. There was no way to address all text applications universally–some had a “selection” property and some didn’t, and each exposed it differently. I decided instead to tie the script to one easily available application with a simple AppleScript Dictionary.

With AppleScript Studio, I don’t think this makes sense any more. It’s too easy to slap a text view onto the user interface, add some menu items, and essentially have all the functionality of TextEdit inside the app. Besides, as someone pointed out to me, copy & paste and drag and drop are pretty universally understood ways to get data into different places.

So Manila Envelope will have more of a text-based application feel to it. Cool. Now it just needs an icon. Anyone with skills want to share?

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.