Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the best-selling Take Control ebooks.

 

 

Pick an apple! 
 
Removing Photos from iPhoto

Despite iPhoto's long history, many people continue to be confused about exactly what happens when you delete a photo. There are three possibilities.

If you delete a photo from an album, book, card, calendar, or saved slideshow, the photo is merely removed from that item and remains generally available in your iPhoto library.

If, however, you delete a photo while in Events or Photos view, that act moves the photo to iPhoto's Trash. It's still available, but...

If you then empty iPhoto's Trash, all photos in it will be deleted from the iPhoto library and from your hard disk.

Visit iPhoto '08: Visual QuickStart Guide

 

 

Related Articles

 

 

Other articles in the series OneClick 2.0

 

 

Freedom of the Button Press - OneClick 2.0

Send Article to a Friend

In the struggle to return control of the computer to the user, macro utilities are indispensable. Such a utility acts as a ghostly simulacrum of a live user, choosing from menus, typing keys, and clicking the mouse; an assemblage of such actions can essentially script the unscriptable, driving any application to customize or automate frequent or repetitive tasks. From my earliest days with the Macintosh, QuicKeys was my constant companion; I've also looked at KeyQuencer. But if I had to use just one macro utility, forsaking all others, my choice, despite its faults, would be OneClick, from WestCode Software.

<http://db.tidbits.com/series/1044>
<http://www.westcodesoft.com/>

Refined Palettes -- OneClick creates floating windows (palettes), each of which can be either global or associated with a specific application. A palette contains buttons; every button has a script, a sequence of actions which you create and edit as text in an easy programming language appropriately named EasyScript. A script can contain various subroutines, called handlers. Handlers are the code that actually gets triggered, and in forming a mental picture of OneClick, it helps to know how this occurs. (Bear in mind that an application-specific palette cannot be visible, nor can its scripts run, unless the application is frontmost.) Here are the triggers:

  • You click and release the button. This triggers the button's MouseUp handler.

  • You click the button and hold down. This triggers the button's MouseDown handler. Such a handler can construct a menu and make it pop up from the button, and then proceed in response to the user's menu choice. Since pop-up menus require that the mouse button be down, this would make no sense in a MouseUp handler. If a button has both a MouseDown handler and a MouseUp handler, the latter will never be automatically triggered; they are mutually exclusive.

  • You type the button's keyboard shortcut. This triggers the button's MouseDown handler if there is one, otherwise its MouseUp handler. A palette does not have to be visible for its keyboard shortcut to work, and buttons on palettes belonging to different applications can use the same keyboard shortcut. Thus, OneClick actions can be triggered purely from the keyboard, as with QuicKeys; this should satisfy those who, like several members of the TidBITS staff, dislike most palettes.

  • You drop something on the button. This triggers the button's DragAndDrop handler. You can drag text (from an application that can initiate true text drag & drop), or Finder items; the script receives the text or the pathnames, respectively, and can respond as desired.

  • Something causes the button to be redrawn - for example, the palette becomes visible, or the button changes its appearance through being pressed by the user or commanded by a script. This triggers the button's DrawButton handler.

  • The palette's associated application (or, for a global palette, the computer) starts up. This triggers the button's Startup handler. For example, if a badly behaved application requires a click from the user to dismiss its opening splash screen, OneClick can perform the click.

  • A certain time period elapses, or a system event occurs. This triggers the button's Scheduled handler. You configure what time period(s) or event(s) will act as triggers, which you typically do in the Startup handler. Common events to which OneClick can respond are: an application starts up or quits, a new window comes to the front, or a OneClick palette is shown or hidden. Suppose you wanted a certain palette to appear in response to the mouse moving over a "hot spot" such as the lower left corner of the monitor. You could configure a Scheduled handler to be called every second, polling the mouse's position and showing the palette if the mouse is at the hot spot.

  • Another handler calls the one in question by name. The calling handler need not be in the same button, nor even in the same palette. In fact, a handler can be called from an AppleScript running anywhere; thus, HyperCard or QuicKeys or even Microsoft Word could trigger a OneClick script.

Clearly there is great power and flexibility in this capacity of button scripts to be triggered in so many different ways. And OneClick's buttons are also customizable: they can contain text or icons, they can be drawn in various ways, in any size or color, and so forth. Thus, a OneClick palette can be made to look just right for its application. Nonetheless, it isn't its system of buttons and palettes which makes OneClick the place I'd prefer to be when writing a macro script - it's the nature of the scripts themselves.

It's the Scriptability, Stupid -- OneClick scripts are text, written in a real programming language with real programming features such as variables, looping and branching constructs, arithmetic calculation and string manipulation, and even a pleasant object-based syntax. And OneClick provides oodles of built-in functions for letting this language do powerful things.

Naturally, you can perform all the ghostly user-like actions you'd expect from a macro utility. You can click the mouse at given coordinates, possibly with modifier keys or dragging. You can type. You can examine menu items, and choose one. You can inspect a button's state, and push it. You can select, scroll, resize, reposition, zoom, or collapse a window; you can even read its text.

You can perform various system- and Finder-level activities. You can manipulate the clipboard; show, hide, and reorder running processes; obtain screen resolutions, sizes, and positions; create, copy, open, and delete files and folders; read or change a file's text or Finder information; and mount or obtain information about a volume.

You can interact with the user. You can put up a dialog, give it customized buttons, let the user type some text into it, let the user choose an item from a list, and show the standard File Open or Save dialog or even the Color Picker dialog. You can supply help text that will appear when the user holds Shift-Option with the mouse over a button. You can change the cursor. You can play sounds, or have the Speech Manager speak some text. You can poll the mouse button or the keyboard; so, by learning what modifiers the user is holding, you can give a button multiple functionalities. You can allow a button to receive something using drag & drop; you can also permit text to be dragged from a button. You can cause various sorts of pop-up menu to appear for the user to choose from: a menu that you construct from scratch, a hierarchical menu of files and folders on disk, a menu showing all the characters of any font, or even an entire palette behaving like a pop-up menu.

You can run an AppleScript script, thus scripting the scriptable as well as the unscriptable. This can be a compiled script file created in Apple's Script Editor, but in most cases it can simply appear inline within a button script.

Finally, everything about OneClick's own buttons and palettes can be controlled from scripts. You can change a button's text or appearance, make a button display a thermometer or pie-chart as feedback, dictate conditions under which the user can reposition a button or palette by dragging, even create a palette and populate it with buttons "on the fly." Thus, palettes themselves become powerful interface tools, where the buttons combine to form some complex live functionality, such as a calendar.

With such power and flexibility, it's little wonder that OneClick is put to a great variety of ingenious uses - some sense of which may be gleaned from WestCode's page of user-contributed palettes. In fact, WestCode sells a number of its own palettes extracted from the full OneClick distribution separately, along with a runtime version of the OneClick engine.

<http://www.westcodesoft.com/FTP-Buttons.html>

Compared to this, my own use of OneClick is rather tame, mostly because I'm conservative about using buttons scripted by others. Still, a survey of my own habits yields a taste of OneClick's possibilities. On my computer are palettes, buttons, and keyboard shortcuts that do the following.

  • Show the font, size, and styles of the currently selected text in Nisus Writer (because otherwise you have to peep into half a dozen different menus to learn this information).

  • Position and size the frontmost Acrobat Reader window nicely, and to zoom it to Fit Width.

  • Fix capitalization and remove extra spaces in clipboard text (to make up for ViaVoice's mistakes).

  • Connect to or disconnect from the Internet, by driving the Remote Access control panel.

  • Implement multiple simultaneous clipboards.

  • Toggle the collapsed setting of the frontmost window or of all other windows.

  • Interfere with the Help key, which I often strike accidentally.

  • Supply PageUp, PageDown, Home, End, Forward Delete, and Help keys, which are missing from my PowerBook.

  • Hide the frontmost application or all others, or bring the Finder to the front.

  • Use the pathname on the clipboard to open a file or folder.

  • Speak the selected text.

  • Toggle the visibility of the Application Switcher.

  • Choose among my various TCP/IP configurations.

Plus, I use some buttons supplied by WestCode to manage text clippings, change speaker volume, open various system folders, manipulate windows and processes, and navigate the Finder hierarchy. Much of the above are functionalities I was previously achieving in some other way; OneClick all by itself makes many other extensions and utilities superfluous.

Yet though I love OneClick and wouldn't want to be without it, using it can be unpleasant and risky. Next topic: the downsides of OneClick.

Cold Shower -- The script editing environment, despite its nice online help and compile-time syntax checking, is crude. OneClick lacks a Find command, a built-in debugger, and notification of runtime errors. So OneClick becomes what I call "guessware": constructing, debugging, or just understanding a script can range from painful to well-nigh impossible. One can develop workaround tools and techniques, but one shouldn't have to, and besides, this will be hardest for the beginners who most need them. The trouble is compounded by hidden traps in the EasyScript language; for example, "for x = 1 to n" will execute its loop even if n is zero, and complex nested function evaluations often don't work - you have to evaluate all the pieces as separate variables first.

If you're not prepared to crash now and then, or for things to go mysteriously wrong, OneClick isn't for you. At various times, such as when I was writing my first book, I had to stop using OneClick altogether, because I couldn't afford such frequent crashes and corrupted data. Even in just the few days writing this review, I crashed trying to open a script for editing, again trying to save a script, and again trying to import a saved button; numerous attempts to load a saved palette failed without notification. Users have reported finding scripts replaced with nonsense, or unaccountable automated actions suddenly taking over their computer; in the past few days I myself have seen weird unsummoned windows flash on the screen, Finder items spontaneously duplicated, and other unexplained phenomena. Palette corruption is a constant danger. Some of these problems may relate to Scheduled handlers: when they fire, they give no indication of what is happening; they can interrupt one another; and there is no way to learn what schedules are pending. This is one reason I am chary of buttons I didn't write myself.

Even OneClick's most basic level of functionality, which presumably involves interfering with the user's mouse-clicks and generating its own to press buttons and choose menu items, is not completely reliable. Sometimes OneClick is just unaccountably slow: I've seen it take well over a second to bring a window to the front in Acrobat Reader; in REALbasic, buttons can be so unresponsive as to be useless; in DiskTop, it's far worse. In Eudora, activating a window through OneClick sometimes activates the wrong one. I've seen arithmetically calculated values occasionally come out the negative of what they should have been. Users report that typing in the script editor window sometimes "falls through" to the application behind.

Nor does WestCode Software's record of commitment to the survival and support of its product inspire confidence. In late 1996, WestCode cautioned me not to review OneClick 1.03, because 1.5 was about to appear; the next actual upgrade turned out to be 2.0, three years later. The 2.0 beta development process was heartening, but progress was glacial, and WestCode often seemed more inclined to fend off the bug reports than to fix the bugs. Many glitches have been left in this release: there is script window corruption when you make a syntax error, keyboard shortcuts involving "a" don't work, and despite claims of Mac OS 9 compatibility, OneClick doesn't work properly with some Appearance Manager or Navigation Services dialogs. Potential users must judge for themselves whether this sort of laxity is venial or suggestive of possible deeper trouble.

The manuals are quite good, but rather out of synch with how OneClick actually works; for example, installation doesn't work the way the manual describes it, some screen shots don't match reality, some documented features (such as the ability of control strip modules to be OneClick buttons) don't actually work, and some important and potentially confusing features, such as the ability to "lock" a button (so that it can be pressed while you're editing a script), are completely undocumented. Also, there are two manuals, one for EasyScript, one for everything else, because WestCode wants to convey that OneClick can be useful even if you don't do any of your own scripting; and some 70 pages of material is repeated in both, which is cumbersome and confusing.

Bottom Line -- For me, OneClick's scriptability, power, flexibility, and downright usefulness outweigh all the negatives I've outlined; and the price is extremely competitive. I do wish that OneClick worked a bit more cleanly, and that I felt more encouraged about its future. Nonetheless, whether you want to take advantage of the many powerful palettes available online, want to clean up and rationalize your computer's interface, or want to tinker, customize, and automate with code of your own, OneClick is a superb macro program with a wonderful interface that deserves your serious consideration.

OneClick typically occupies less than 500K of RAM, and is about a 7 MB installation. OneClick costs $60 for the downloadable version with two PDF manuals, or $80 on CD with one printed manual; the printed scripting manual is $20 more. OneClick requires System 7 and a 68020 processor or later.

 

READERS LIKE YOU! Support TidBITS by becoming a member today!
Check out the perks at <http://tidbits.com/member_benefits.html>
Special thanks to David Rikert, Mike Cohen, Bill Newton, and frank
smith for their generous support!