Automator
One feature that's always intrigued me about OS X is how powerful yet fairly accessible of a scripting language AppleScript happens to be. Despite its relative ease of use, I hardly ever found myself using AppleScript to get things done. I never seemed to have enough time to sit down and become comfortable enough with the language, regardless of how much easier it would make my life.
Tiger brings another tool to the table that can work either with or in lieu of AppleScript for those who aren't interested in learning the language, and that tool is called Automator. One underlying theme of features like Automator and Dashboard in Tiger is to take functionality that was essentially present in Panther, and make it something that's accessible and actually used by the masses in Tiger. With Dashboard, Apple has taken many of the features of Sherlock - a rarely used and rarely talked about tool in Panther, and re-packaged them in a much more user friendly environment that is Dashboard. With Automator, Apple has taken many of the types of tasks that you can accomplish using AppleScript and made them infinitely more user friendly.
To the end user, Automator is basically a drag-'n-drop batch job generator that happens to be very flexible. Automator allows you to create a workflow of actions, with each action performing specific tasks on its inputs and passing it along to the next action. For example, one of the actions that ships with Tiger is an action to get all image URLs from a web page in Safari. With all of the image URLs, you can then feed them into another action to download all of the images to a specific folder. You can then feed all of those images that you've just downloaded into another action that scales all images to a certain size. The workflow that I've just described can be even more complicated, taking the scaled images and doing pretty much whatever you'd like with them - you can even nest workflows inside of other workflows to achieve even more robust results. What's most important about Automator is that all of this is done in an extremely simple and easy-to-use manner.
You select the category of action from the left; the actions are grouped according to what applications with which they are associated. Then, you select what action you want to perform and drag it into the right pane to add it to your workflow. The workflow is linear and doesn't branch, so anything at the top of the workflow feeds into anything below it. Automator handles all error checking and will warn you if your workflow is going to do something destructive to files or if you are feeding the results of one action into another that isn't compatible (e.g. sending image files into an action that is expecting a URL to be inputted). You can also search for the action that you're looking for using the search box at the top of the Automator window. However, keep in mind that the search box doesn't search descriptions of the actions, just their titles - so searching for "resize" won't bring up anything, but searching for "scale" will bring up the scale images action (somewhat silly considering how big of a deal searching is within Tiger).
The potential for Automator is tremendous. However, I found myself wanting many more actions than what is supplied with Tiger. Although Apple has pretty good documentation on their developer site of how to create your own actions, doing so basically nullifies one of the major attractions to Automator, which is bringing this sort of automated functionality to the masses. There are presently some Automator actions that are available for download from Apple's web site. With further development and support from the community, Automator could very well become one of the most useful items in Tiger, but as it stands now, I'm not sure how much use the majority of users will get out of it.
Facebook
Twitter
RSS
55 Comments
View All Comments
aliasfox - Monday, May 2, 2005 - link
#31What you're forgetting is that in 1995-6, Apple wasn't losing money, it was hemorraging money. In 1995-96, Apple was irrelevant in regards to innovation of any sort. In 1995-96, Apple was selling PowerBooks with batteries (made by Sony, no less) that caught fire. When Jobs returned to Apple in '97, Apple's stock price hovered in the low teens.
It doesn't matter all that much that Apple's marketshare hasn't grown as fast as the rest of the market (and yes, it is growing- Apple recorded most Mac sales in one quarter last month), in absolute numbers, it's not shrinking. And Apple is making money, which is more than Gateway (who has a bigger marketshare than Apple) can say.
The goal of any company is to make money, regardless of size. In this respect, Jobs has succeeded. It doesn't matter if it was the Reality Distortion Field or if it was amazing marketing or if it was quality products that got Apple there.
downtowncb - Monday, May 2, 2005 - link
#43 "The bottom line is that [recoding Mac OS software for x86] will not be a big issue for the majority of developers, as you had originally argued."My original argument (#34) said nothing about Apple switching to x86; you must mean #39 by melgross.
I simply meant to state that Apple hardware and software work together to increase Apple's bottom line. Sorry if that was unclear.
msva124 - Monday, May 2, 2005 - link
>If you want an example of an obscure motherboard, I believe that the TMC Ti5tv qualifies but perhaps not.How does the TMC Ti5tv require Microsoft OS developers to deviate from programming for the x86 spec as usual? You stated before that programming around obscure hardware causes development problems and bugs, and gave motherboards as an example. I will not waste my time contacting Microsoft, since they know as well as I do that your argument is an unproven hypothesis. A hypothesis that is contradicted by the stability of x86 Linux, and unsupported by any sort of scientific evidence or systematic testing.
>Programs for x86 that use hand written assembly code or are othersiwe highly optimized would need to be redone. But whether this is "most" programs or not I don't know. Certainly not every single program, that is true.
I doubt that even 20% of mac software uses any assembly language whatsoever. Within that 20%, it is typically just one or two heavily optimized loops per program, which would take little time to recode for the x86 platform. The bottom line is that it will not be a big issue for the majority of developers, as you had originally argued. In fact, that argument is so preposterous that I can only assume that your initial post and all subsequent ones were flamebait. I will not respond to any more of your posts until you can convince me otherwise.
downtowncb - Monday, May 2, 2005 - link
msva124,If you want an example of an obscure motherboard, I believe that the TMC Ti5tv qualifies but perhaps not. If you need other examples of obscure hardware Windows supports, contact Microsoft.
Programs for x86 that use hand written assembly code or are othersiwe highly optimized would need to be redone. But whether this is "most" programs or not I don't know. Certainly not every single program, that is true.
If Apple isn't taking away from the Windows market, then which market is it taking away from? If we're talking percentages, something's got to give. Not that Microsoft's growth in terms of numbers of copies of OS sold won't outpace any such loss to Apple or whoever. I'm curious as to what you think.
Jbog - Monday, May 2, 2005 - link
#39 melgross, you say Apple directly competes with MS on the OS front. You also say Apple has always had different hardware. Sounds to me it's more like Apple trying to come up with more appealing OS in order to sell its platform. I mean, you can't just buy Tiger OS and replace Windows XP.If any strong argument can be made, it would be between Windows and Linux instead. One can migrate from Windows to Linux without having to buy a whole new set of hardware. You can even dual-boot Windows and Linux.
msva124 - Monday, May 2, 2005 - link
>If Apple were to change to an x86, then every program would have to be redone. That would be almost impossible for the many Mac developers out there .Most OS X programs are written in C or Objective-C, using the Carbon or Cocoa apis. Only those apis must be ported to the x86 platform, not every single program.
>Apple's increase in marketshare takes away from the Windows market itself
Right, except it doesn't.
melgross - Monday, May 2, 2005 - link
#32 Most of what you said is ridiculous.First of all, Apple's market share is growing. Of course other platforms sales aren't Apples sales. But most other sales aren't either Apple/Sun, etc.
This is mostly an Apple/Wintel market. Sun is only servers and Apple doesn't compete much in their space yet. Apple's server sales are increasing, but are only now ramping up. Except in the scientific Unix space, Apples server sales would be against Windows servers. They don't yet have the breath to compete in the higher areas yet.
Otherwise, it's Apple vs. MS.
Sure, other pc companies, or rather company (Dell) are growing, but that takes sales away from each other. Apple's increase in marketshare takes away from the Windows market itself. If Dell takes sale from Gateway, it's still a sale for MS. That's the point.
I suppose that Apple is taking away a few Linux sale as well, but it's almost all MS's.
All AMD did was to finally come out with better processors that they could actually make, rather than just announce, and then NOT make. While the 64 bit extensions was a little balsy, it's true, it didn't take away from their chips either. Even if it didn't go over, the chips would still have had the same characteristics as before. The extensions would not have been used, that's all.
Apple does directly compete with MS on the OS front. Apple has always had different hardware. When Apple went to the 68000 rather than the 8088 way back when, there were few arguments that the 68000 was not a better chip. Apple simply went on through from there.
If Apple were to change to an x86, then every program would have to be redone. That would be almost impossible for the many Mac developers out there . It's just like the Itanium. Little software development has been done for it. Why should Apple be caught in that trap?
michael2k - Monday, May 2, 2005 - link
If you want to call it "RDF", that is your choice.I'm using Microsoft's publically announced information to compare Longhorn to Tiger.
Nothing I've mentioned is 'rumored'. It's all been 'confirmed' by Microsoft.
WaltC - Monday, May 2, 2005 - link
#33 "Um, you do know from 1985 until 1996 Steve Jobs had no presence at Apple?"I believe I said the better part of the last decade to begin with, as I recall...;) Yes, I know that he was originally fired/pushed out by the Apple board around '85 and went on to NeXt--which failed, btw.
#33 "Release a simple, affordable, powerful, computer in 1984: Original Mac, which became a strong model of the computing industry for the next 21 years."
Oh yes--I suppose that's why the board fired him in '85...;)
33# "Release a powerful, modern, OS and computer in 1989: NeXTStep, which is now the foundation for Mac OS X and is now Tiger, and is AGAIN a strong model for the computer industry (Longhorn, Linux)"
Both NeXt and NeXTstep failed commercially as I recall. The "foundation" for OS X was kind of forced into play, you know...;) And, it was years late and initially very lacking in promised features (many of which it still lacks.)
#33 "Create the world's most popular mp3 player, the iPod, in 2001: It's a computer in every sense of the word, with a display, input, storage, and output functionality. It's 'revolutionary' status is because it was the first, smallest, fastest, highest capacity (all at once) device, though there were smaller, with smaller capacities, or larger, with larger capacities, and none with faster upload or UI in 2001."
Sorry, but the iPod is *not* a personal computer. But that's RDF thinking for you without a doubt...;)
#33" Again, as for why compare Longhorn to Tiger?
Because everything Longhorn WANTS to do, Tiger does.
Longhorn wants a DBFS, called WinFS, not due until next year. Tiger achieves 90% of that now, and by next year will be even better.
Longhorn wants better search, to be achieved with WinFS, not due until next year, when Tiger has Spotlight now.
Longhorn wants a 3d accelerated display layer, and is not due until next year. OS X has achieved that since 10.2 in 2002 (a small step with hardware accelerated compositing), now more fully implemented since 10.3 and 10.4 with 3d and 2d acceleration, and with even more to come by the time Tiger comes out.
Longhorn wants a 'modern' UI, which is not due until next year, where OS X has had it since 2001, with each year bringing out more usability and functionality to the UI (Dock, transparency, animation, Expose, Dashboard, etc).
Longhorn wants better security, again not due until next year, while OS X has it now, and since 2001
Longhorn wants a shell and CLI, again next year, while OS X has had it since 2001
You ask why we compare: I think it's stupid NOT to compare. Longhorn wants to be a 'next generation' OS, and it's prototype and model 'next generation' OS is available now, and has been for four years, in Mac OS X.
We're not the only ones comparing. As I said before, Allchin of Microsoft has made direct comparisons, to Microsoft's detriment."
Ah, yes, the RDF again...;) The truth of course is that *nobody knows* what Longhorn will be since Longhorn is a long way out. I see nothing wrong with a Tiger-x64 comparison because MS is *shipping* x64. Pretty simple, really.
superduperjacob - Sunday, May 1, 2005 - link
Anand - on page 7 you say:"To remove a widget, you have to still be in the add/remove widget mode and just click the x that appears next to all of the widgets."
If you hold down the option key in normal widget mode, the x appears and you can close the widget.