Category: ManilaEnvelope

Brent points out that there’s a non-trivial cost to supporting multiple kinds of weblogs in a blog front end tool like NetNewsWire or Manila Envelope. Weblogs may look alike on the surface (and to an RSS aggregator), but they’re all different software platforms underneath and accordingly have different information needs. This is fine as long you don’t have to expose the mess to the user.

This is one of the reasons, I think, why the MetaWeblog API came about. Abstracting the common elements of the data elements into a new API layer is smart. Unfortunately not all the platforms support it…

Sincere apologies for the temporary triple posts. It looks like I got false error messages from Manila Envelope making me think I had to repost. Ah well. Another day, another bug.

After the big release of 1.0.3a on Tuesday, a reader in England found some bugs I had missed in the first go-round with Manila Envelope on Jaguar. Specifically, people using the software for the first time can’t post!

The problem was a result of two things. First, the problem with Jaguar requiring plain text for XML-RPC extended into an additional function call that I hadn’t investigated, one that passed a URL as one of its parameters. This particular call only happens if no successful calls to the server have been made before, so I didn’t catch it in my haste to release 1.0.3a. Once again the importance of thorough testing…

Second, I made a big fuss about the importance of separating user interaction from business logic back in February, but didn’t catch all the problem areas. This particular problem was caused by a function that returned a string value. In the first implementation, I had the calling functions make the assumption that an empty string meant an error had occurred. Only problem: if the calling function in the UI is handling error notification and I’m returning a single empty string parameter, there’s no way to provide detailed error information.

This is where I miss “pass by reference” in other programming languages. It then becomes simple: you pass in a variable to be transformed by the method, and you check a return value for success or failure. Instead, I am using multiple return values:
return [Macro error: Can't compile this script because of a syntax error.]

which means I have to use AppleScript’s copy syntax instead of a simple set. Ah, growing pains.

The release notes are here. This version adds Jaguar compatibility. It has not been tested with pre-10.2.1 versions of Mac OS X; feedback is appreciated. Also noteworthy: this version now uses XMLRPC exclusively. You can download the software here; source code is also available.

I’ve deliberately avoided adding new features in this release since it took me so long to get the Jaguar bugfixes figured out. But there may be a couple of new features coming soon.

A while back after installing Jaguar I found that Manila Envelope no longer worked, or worked only intermittently. I upgraded to 10.2.1 last night, and I don’t know if this has anything to do with it, but it worked again–for about two minutes. I posted two test posts successfully to the editing region, but now it’s not working at all.

Did Apple break something in 10.2? I’d love to know. One possibility is the new Core Foundation web services framework, which has probably been shimmed under the existing AppleScript SOAP support introduced in 10.1 (at least, that’s how I’d do it). Another possibility is that something broke in the CFString search and replace functionality that I use to do fancy text processing. Debugging it is really really painful.

At least I have wireless. I had forgotten about my Wayport membership. My flight takes off in another hour or so, and I can’t wait. It’ll be the first time all week I’ve had any sleep.

So Manila Envelope doesn’t appear to work as is under Mac OS X 10.2. In fact, even rebuilding it doesn’t do the trick. Never fear, I’m working on it, but I can’t figure out what the hell is wrong…

After a long hiatus, I’m starting to get back into Manila Envelope again. I had a minor breakthrough this morning that allowed me to get the message number for newly created news items. This by itself doesn’t do a lot for the user, but when combined with the ability to retrieve a post from the server and change the content of an existing message, it’s laying groundwork for the ability to edit the last post made.

Other work: changing the site tagline from inside Manila Envelope. And still trying valiantly to figure out how to convert italic and bold styled text to HTML tags.

…to everyone whose RSS feed I destroyed this morning. It seems the problem was an extra quotation mark inside an <a href> tag.

I generally make changes to my tools to scratch an itch, and I’m feeling two itches now:

1. Some way to ensure the validity of my anchor tags before I post them (whether it’s having the tool build the tag for you, or running a validator before posting, or something)
2. A list of recently posted items with buttons for “Edit” and “Delete.” It’s very hard, almost impossible, to edit a news item with a mangled anchor tag using Manila—maybe I can come up with something that works from Manila Envelope.

Brent says that doing a Cocoa weblog editor “should be a piece of cake.” Maybe he and I should get together. Manila Envelope, after all, is AppleScript Studio, and that’s Cocoa with some AppleScript to glue it together.

What about it, Brent? Want to lend some Cocoa knowledge and help out?

Manila Envelope 1.0.3 has been released. See the release notes. In particular, note that department names with spaces will not work with the new department names feature.

The crash I was experiencing before when updating department names multiple times has gone. I think the lesson is that you need to either update an array in a plist with an array of the same length, or to change it to zero length and write the new array.

Shortly after I posted my last cry of despair over random crashing, I downloaded a new example AppleScript Studio project that contained a Cocoa string replacement method, rather than the one I had been using before which toggled AppleScript’s text delimiters back and forth. Making the switch cost me nothing in execution time and appears to have eliminated the crashing bug. I had to alter the Cocoa method so that it wasn’t doing case insensitive searching, but otherwise easy as pie. Next one… crashing when updating the department list.

On a tip from a mailing list, I tried a change to Manila Envelope this morning to see whether I could stop an intermittent crashing bug. The change may have stopped the crashes, but unfortunately it also screwed up the text being posted quite badly. Apologies to all who were confused by posts on the page (or in the RSS) that said something like: “tMcWrldTky,pplennuncedBluetthsupprtfrtheMc”.

For the record, if your script is designed to convert accented characters to HTML entities, it’s a bad idea to convert them to Unicode first. It apparently converts them down to regular unaccented characters rather than their proper Unicode entities. When you search and replace on a regular vowel, this is what you get…

I’ve made more progress on the next version of Manila Envelope. It will now cache department names retrieved from a Manila site.

There’s one lingering issue — the problem with spaces in department names. If I can get that fixed I’ll be home free.

It’s been quiet on the programming front. I’m getting smarter in Cocoa and AppleScript. Here’s a feature that’ll be coming in 1.0.3 – a News Item Department drop down list that syncs with your Manila blog.

Here’s where I am:

• The RPC call works
• I can basically parse the XML that gets passed back (though all the department names are lowercased and I’m not sure what’s up with the vertical bars around one department)
• I can populate the dropdown
• The above three steps are triggered temporarily from a button. I need to add UI to get the departments in the first place, cache them in the prefs file so I don’t have to hit the website every time, and add more UI to refresh the categories if they get out of sync.

So it’ll take a while longer for me to finish up. But I thought this would be the hard part and it’s done already. Now I have to figure out how to use some of these Cocoa functions to write a list into a plist file as an array. Dig we must…