Category: ManilaEnvelope

Dave asked for a screen shot for all the “Mac-impaired people” out there… so here it is.

I just released Manila Envelope 1.0. It’s a native Mac OS X app, written in AppleScript Studio, that allows posting to a Manila-compatible site via SOAP.

I think this is what Dave was asking for last week with respect to Watson. But my app isn’t a screen scraper–it is a non-browser-based simple native blogging tool that uses the Manila API.

The software can be downloaded from my software and scripting page. Source code is available, not because I’m an open source movement guy (I’m not) but because AppleScript Studio is a young environment, I don’t understand it very well, and I figure other people can learn from my pain.

You can read about the development of Manila Envelope by clicking on the application icon to the right.

It looks like preferences have been broken for almost two weeks in Manila Envelope because, while rewriting the code on the train, I swapped the order of two arguments to a function. Two weeks!!! As Dave says, “We make shitty software….with bugs!!!”

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.

I didn’t update about Manila Envelope yesterday because I didn’t do a lot of successful things with it. I hit a few snags in AppleScript Studio, some having to do with getting data or states from controls and some having to do with lack of visibility in the debugger in certain situations.

However, I do have news items working (albeit with one major hack). One snag I ran into: “title” is now an AppleScript Studio reserved word (along with “password” and “URL”). This means that if you are populating a SOAP structure that has “title” as one of the element names, you have to escape it using vertical bars (e.g. |title|:myTitleVariable) or else AppleScript Studio just plain doesn’t include it as an element in the structure. I had learned this with password and URL the hard way before, but title is a new one. I could say something learned and witty about the importance of avoiding namespace conflicts in published interfaces, but (a) I’m too groggy from fighting this thing and (b) after all, Dave et al didn’t have AppleScript naming standards in mind when they were writing the interface.

I withdraw my previous objection about password text fields. It is pretty well hidden, but here’s how you make a text field into a “secure text field” (one that hides the user’s input behind bullet characters): select the field, in the Show Info window select Custom Class from the drop down menu at the top of the window, and click NSSecureTextField in the list of available classes. Build and run–the field now shows bullets as you type.

Success! The first story posted from Manila Envelope is on the Stories page now. News Items are not implemented yet, but this is a major breakthrough. Now that I’m sure I’ve got the SOAP stuff working, I can concentrate on adding features.

Good morning! I did some pretty intense work last night on ManilaEnvelope. I still don’t have it up and running (for that matter, I haven’t decided whether the name is all one word or two), but I have some new insights on AppleScript Studio.

Other changes to make ManilaEnvelope work in AppleScript Studio: Properties don’t persist across runs of the application. Guess this means I have to learn to work with preference files. 🙂

I started writing the next generation of my Applescript-based tool for posting to Manila last night using AppleScript Studio. The first pass was just to host some of the existing scripts in an AppleScript Studio based application and get them to work. I got it working partway but I think ASStudio (I won’t fully abbreviate that, for reasons that should be obvious) uses different mechanisms for accessing functions contained in separate script files. I need to dig a little more deeply.

By the way, the name of the tool will be Manila Envelope (sorry for the bad pun). I plan to wrap as much functionality to access Manila inside the tool as possible while still making it pretty seamless to use.