Category: Software

It’s not work, just fun

I’m playing around a bit more with Radio UserLand. It’s going to take some patience to make it work, as I really want to get it to point at this site and not at my Radio Weblog. Meanwhile I’ve decided how to move forward on Manila Envelope, which was felled right before launch with an impossible problem with the preferences. I’m going to have to write my own code to write and read an XML preference file. Should be fun. Dig we must…

Universal: why we’re afraid of our customers

Okay, so I posted a complaint at Universal’s site like a lot of other people, which is why I got the following message today. I’ve highlighted in red the two bits that I find interesting:

From: “MusicHelpOnline.com Support”

To: [my email]

Subject: MusicHelpOnline Support

Date: Wed, 09 Jan 2002 15:01:20 -0600

Thank you for your feedback regarding copy protected CDs. We
appreciate your opinion, as the consumer experience with the music we all
love has always been a priority at the Universal Music Group.

Unfortunately, over the last few years, the music industry has been faced
with a growing problem of unauthorized CD “ripping” leading to illegal
Internet distribution of music – a practice that is hurting everyone from
recording artists to songwriters to record stores. This illegal copying is
taking place on a massive scale, with literally millions of copies being
made without any compensation to the creators of the music. If a way is
not found to protect the music from these abuses, recording artists,
songwriters and many others will be deprived of their livelihoods. The
changing economics could cause fewer new artists to get a chance to find
their audience.

Universal Music Group is committed to protecting the rights of our artists,
songwriters, and copyright holders, and, like the rest of the entertainment
industry, is evaluating emerging technologies to assess their viability while
also attempting to maximize the consumer experience. In addition,
Universal is exploring new ways to make music available in a variety of
online formats. We are also working with technology companies on new
offline formats that appeal to consumers.

We have licensed copy protection technologies developed by others and
are experimenting with the integration of those technologies into some of
our CDs as a first step in measuring their effectiveness in an evolving
marketplace. While the CDs with copy protection may not be playable in a
limited number of CD players, UMG is currently working with our
technology providers to achieve 100% playability. We also hope to
include Macintosh-based playability on copy-protected discs in the future.
We have not finalized our plans for 2002 nor have we made a commitment
to put copy protection on all of our CD releases.

UMG has also established www.musichelponline.com to provide
consumers with support and to answer any questions you may have
concerning copy protected CDs.

We appreciate your business, and your support for the musicians who
bring so much to all of our lives.

Unexpected snag

I’m going to have to delay the release of Manila Envelope. When I used it yesterday morning it was working, and now the preferences have broken. This, I guess, is a danger of using someone else’s code without fully understanding it. I’ll have to do some digging through Cocoa to figure out what’s going on.

In the meantime, I’m hitting the road after a great night’s sleep at my in-laws in New Jersey. Next post will be from Washington, DC.

Manila Envelope – Part 9b

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?

Manila Envelope – Part 9

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.

Manila Envelope – Part 8

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.

Manila Envelope Part 7

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.

Manila Envelope – Part 6

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.

Manila Envelope – Part 5

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.

Thanks and keep the feedback coming

I kind of paused this morning after I wrote the last entry. I’m surprised looking back at it that I’m still working on these scripts. I mentioned the first script I was going to write in July, half joking, in an email to Dave when Apple announced they were going to be baking in SOAP support in 10.1. I wrote the script when I got 10.1 more as a proof of concept than anything else. It works reasonably well. Why am I going forward?

Well, I never had the time to learn all the stuff I wanted to know to program in Cocoa, for one thing, and this is a quick way to learn Interface Builder and some of the other tools in the free Dev Tools IDE. There have been other features that I’ve wanted to add to my existing scripts–it bugs me, for instance, that you type your password in plain text in a dialog box, and that there’s no interface for clearing your stored information.

But mainly I’ve had feedback from a number of people who have convinced me that this stuff is worth investing time in. One, the server guy at a major state university, wanted help in getting his faculty to use the web for knowledge management. (I still haven’t added his feature. Soon, hopefully.) A few scripters have thanked me for the effort I had put in because they use the tool every day.

It’s great to know people are out there reading and blogging. If you find my tools useful and you have suggestions for how to improve them, or just want to drop me a line, please do. My mailbox is open, and as soon as this last paper’s done I’m going back to do some more scripting.

Manila Envelope – Part 1

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.