(Yes, D&D players this is ongoing comedy from the attempt to update Gametable. Quiet!)
I've recently being using Automator and I have to say, I don't care for it. It works pretty good until you hit some sort of hard limit. Here's the part it does well: I can run the action, browse files and select an image. Automator has an image editor (I use Pixelmator) resize the image, do some quick & dirty auto-leveling, resize the image to a suitable-for-the-web size, and then upload it to online storage. I'll admit all this is pretty fantastic, although I suspect I could do it with Applescript.
The problem is after that I have to use a web page, enter the filename of the image and enter a text string description. If I screw that up, even up to the point of typing '.jpg' instead of '.JPG' then the web software screws up. It can derail momentum of our D&D combat. The answer is obvious: the Automator action needs to update the web application as well. It's pretty easy for me to write a new bit of code so there's a URL that takes the information - all I need to do is construct a URL.
Oh.
You see, Automator has variables, but it doesn't have anything like *operations*. And you basically only have one argument passing from one Automator action to another. To have *TWO* arguments you have to save one into a text file and pull it back when you need it. If I have two arguments "foo" and "bar" and I want to create a url that looks like http://www.foo.com/special/url/?&name=foo&description=bar, well that's not a very Automator sort of thing.
I messed with it for a while and got as far as getting Automator to spit out a single text string that looks like (in C terms) "foo\nbar" (in English that's foo, (carriage return) bar.)
I finally decided to punt: I'm going to write a Ruby script that grabs that arguments and builds and sends the URL. Long-term I think I'll see if i can write an Applescript that presents the UI and does all the work. If not I could throw it together pretty quickly as a real Mac application, but c'mon.
I've recently being using Automator and I have to say, I don't care for it. It works pretty good until you hit some sort of hard limit. Here's the part it does well: I can run the action, browse files and select an image. Automator has an image editor (I use Pixelmator) resize the image, do some quick & dirty auto-leveling, resize the image to a suitable-for-the-web size, and then upload it to online storage. I'll admit all this is pretty fantastic, although I suspect I could do it with Applescript.
The problem is after that I have to use a web page, enter the filename of the image and enter a text string description. If I screw that up, even up to the point of typing '.jpg' instead of '.JPG' then the web software screws up. It can derail momentum of our D&D combat. The answer is obvious: the Automator action needs to update the web application as well. It's pretty easy for me to write a new bit of code so there's a URL that takes the information - all I need to do is construct a URL.
Oh.
You see, Automator has variables, but it doesn't have anything like *operations*. And you basically only have one argument passing from one Automator action to another. To have *TWO* arguments you have to save one into a text file and pull it back when you need it. If I have two arguments "foo" and "bar" and I want to create a url that looks like http://www.foo.com/special/url/?&name=foo&description=bar, well that's not a very Automator sort of thing.
I messed with it for a while and got as far as getting Automator to spit out a single text string that looks like (in C terms) "foo\nbar" (in English that's foo, (carriage return) bar.)
I finally decided to punt: I'm going to write a Ruby script that grabs that arguments and builds and sends the URL. Long-term I think I'll see if i can write an Applescript that presents the UI and does all the work. If not I could throw it together pretty quickly as a real Mac application, but c'mon.