Aperture's peculiar selection behavior - primary only

Aperture can't manage iPhoto metadata that I care about, such as comments associated with albums. So I can't use it as my media management solution, but I'm still seeing if I can use it as an image editor.

It's not doing so well.

One of the peculiarities is 'select primary'.

It's easy to set this mode by accident -- an errant touch of the S key will do it. In this mode even if you select multiple images in the UI, one is "primary" (the first selected). Operations apply only to the Primary.

To disable this mode either unselect it in the Edit menu or type S again.

I'm sure it's a useful mode for a serious Aperture user, but it's awfully easy to set it by accident. Of course Aperture is a pro tool, while what I really want is iPhoto Plus (with !$%@ Library Import capabilities).

BTW, there's an obvious bug in Aperture. Switching to Quick Preview mode should place a checkmark in front of that item in the View menu. It doesn't.

Update 3/2/2008: Well, I'm still at a loss. Even when I disable Select Primary mode an adjustment operation is only applied to the Primary image. This could be a bug, or just odd design -- equally probable I'd guess. Aperture has always had quality issues for me. Aperture doesn't have integrated Help functions (another budget cutting move), and the old PDFs aren't even on the Help menu (a last minute delivery bug), so it's a pain to investigate. Despite delivery version 2.0 the product still feels like it's on life support.

Update 3/2/2008: From the awkward PDF only documentation:

You can apply an adjustment or group of adjustments to a range of images by first applying the adjustments to one image and then lifting the adjustments from the first image and stamping them on the other images. You do this by using the Lift and Stamp tools and the Lift & Stamp HUD.

So if you want to get started by applying an auto-adjust function you can't do it in two clicks, you have to use extra clicks. Why?

Update 3/2/2008b: From Apple Discussion.

...If I just copy an adjustment of the auto level from an image to others, i think the copied auto level is only based on the first image...

...That's correct. There's no way to auto-level multiple images at once in Aperture...

In other words, even using the awkward Lift and Stamp operation, you only apply the results of the image-specific auto-level setting to multiple images, you don't auto-level each in turn.

Bizarre.

Don't buy your iPhone yet

This is why I decided I wouldn't buy an iPhone until I saw exactly what the SDK would be:

iPhone/iPod SDK: Apple to approve, distribute apps, limit add-ons

...No accessory connectivity. Under current plans, SDK developers will be prevented from interfacing directly with Dock Connector-based accessories connected to the iPhone or iPod touch—a decision that we are told could cripple development of new accessories such as physical keyboards, traditional add-ons, and more ambitious, creative accessories such as Delphi’s iPhone car control prototype. One source described this limit as a guarantee that SDK-developed applications would be nearly as limited as current web-based ones, while consuming more of the device’s storage capacity. Yet integrated iPhone or iPod touch features such as the phone, Wi-Fi, and camera will be developer-accessible, certainly permitting development of programs that weren’t possible before. It is presently unclear whether Bluetooth 2.0, which is included in the iPhone but crippled to permit only monaural phone call streaming, will be opened to permit stereo audio streaming and data functionality as well.

Sources told iLounge that the collective impact of Apple’s decisions will be to control and stifle third-party development at a critical juncture in iPhone and iPod history, limiting what could be an open, thriving Mac-like collection of applications and accessories to a smaller, more stagnant iPod-like controlled environment. Consequently, a source suggests, developers who “jailbrake” iPhones and iPods to develop applications will be at an advantage relative to those who use Apple’s official tools...

No keyboard. No GPS. Nasty. All because Apple needs DRM control of movies, and has to block digital outflow by the port. I suspect they'll lockout Bluetooth for the same reason.

I want to see what it will be possible to sync across the dock. If sync is disabled I may decide to wait for the gPhone.

Use your headphones for iPhone calls -- with a Griffin SmartTalk adapter

I figured that when I buy an iPhone I'd also buy a Bose Communicator kit to go with it. Turns out there's a better, cheaper option:

Macworld | Review: iPhone headphone adapters

...The answer is to buy an iPhone headphone adapter, offering an iPhone-compatible mini plug on one end and a button and microphone on the other end, along with a place to plug in whatever headphones (or speakers, or cassette adapters — basically anything with a mini plug) you might have, as well as a clip to attach it to some part of your clothing close enough to your mouth to pick up your end of the conversation...

...The best of the bunch was the Griffin SmartTalk, a real bargain at $20. The SmartTalk’s microphone/clicker module is excellent, a compact block with a small integrated clip. The module was the least obtrusive of the ones I tested, and its button was easy to double-click when I wanted to switch tracks. Its microphone also offered the best sound quality of any of the adapters we tested, providing clear sound with a minimum of noise. The SmartTalk’s cord is wrapped in nylon, which makes it feel a bit classier than the rubber coating on the other adapters.

Besides being half the price of the Bose kit, the SmartTalk works with any headphone set. The Bose kit only works with newer versions of their headphones.

I don't think this would work all that well if the output was going to a car stereo though. Be real tough to avoid feedback with that setup ...

Microsoft Access: Snapshot and Dynaset recordset queries - what the heck are they?

Using Microsoft Access is a bit like being in an Indiana Jones movie. There are dark and mysterious ancient temples to explore, hidden treasures, snakes, spiders and the occasional death dealing trap. The scrolls that would explain everything are all losts in the mists of time, before there was a web.

It keeps me from boredom.

Yesterday a complex and powerful set of nested subqueries began retuning unpredictable results. Yes, I'd again broken Microsoft Access. It seems that Access was getting variable results depending on the sequence of subquery execution, such that it couldn't decide if a value were NULL or not.

So I tried to figure out if setting the sub-query(s) (recordset) to behave as a "Dynaset", "Dynaset (lazy update)" or "Snapshot"  would make any difference.

First, of course, I looked for documentation on what the differences are. It's not in the Access Help files. Google found precious little at first -- one of my page one results was a post I wrote in January 2006!)

This search worked better: recordset, dynaset, snapshot.

From it I got a few references:

O'Reilly Network -- Access Design and Programming Tips

But it is important to remember that DAO (Data Access Object) provides several forms of recordsets: table-type, dynaset, snapshot, and forward-only. The point here is that if a snapshot or forward-only recordset will suit your purposes, you should use it, because it will be more efficient and therefore your code will run more quickly.

Snapshot recordsets are faster to create and to access than dynaset recordsets, but they use more memory because the entire record is stored in memory. The downside is that you cannot update the records in a snapshot recordset.

Forward-only recordsets are like snapshot recordsets, but you can only move forward through the recordset.

Ultimately, the only way to tell whether you will save significant processing time is to try the various suitable recordset types in a given situation. The point here is to not fall into the habit of always creating a table-type or dynaset-type recordset.

and

DAO Object Model The Definitive Reference Chapter 8 Recordsets Collection and Recordset Object

...There are five types of recordsets: Table-type, Dynaset, Snapshot, Forward-only, and Dynamic. (See the Type property section for a discussion of recordset types.) Each Recordset object contains a collection of Fields that represents the fields in the underlying table(s). You can list the field names and values, but you will just get the values in the current record, unless you first go to a particular record. For example, the following code moves to the last record in a recordset and lists the field names and values for that record:...

Recordset Property Summary which shows almost NO difference between Snapshot and Dynaset.

But then we come to the precious table 8-13:

Dynaset: Represents a table or an updatable query. Supports the AddNew, Delete, and Find* methods, but not the Seek method.

Snapshot: A read-only recordset; useful for finding data or printing. Does not allow updating, except in the case of an updatable Snapshot in an ODBCDirect workspace. Supports the Find* methods.

Elsewhere I read

Dynaset:
1. Can be formed by large number of tables resulting in Virtual Tables.
2. Does not store on the Machine but occupy temporary memory that is RAM.
3. The changes made in the database can be reflected in the this.
4. Allows operations like edit and update.

SnapShot:
1. Creates table on the machine and occupies space of the memory.
2. Does not allow edit and update operations.
3. Can be used for small amount of data.

Another source (lost) said a Snapshot is often quite a bit faster in a query than a Dynaset, but the speed requires more memory use.

By extension of the above, I imagine "Dynaset (lazy update)" is an extension of Dynaset with some of the speed of a Snapshot but the possibility of doing updates (delayed or lazily).

So, after all that, did changing some of my subqueries to "Snapshot" fix the problem of the "Schrodinger's Cat" results that were sometimes NULL and sometimes NOT NULL?

Yes, it did. The results were much faster too.

Google Sites versus Google Page Creator

Google Sites was launched today for all Google Apps:

Google Sites Launched

Google finally launched a service that uses JotSpot's technology: Google Sites. The new service is a part of Google Apps and allows you to create web sites collaboratively. 'People can work together on a Site to add file attachments, information from other Google applications (like Google Docs, Google Calendar, YouTube and Picasa), and new free-form content. Creating a site together is as easy as editing a document, and you always control who has access, whether it's just yourself, your team, or your whole organization,' explains Google.

Google offers templates, a rich-text editor, 10GB of storage for each Google Apps account and integration with other Google services so you can embed gadgets, calendars, spreadsheets, presentations, photo slideshows and videos. You can invite people to collaborate or just view a site and you can also publish the site so that anyone can view it.

I played with it on my MN Special Hockey Google Apps domain.

Some quick impressions:

1. The basics are very similar to Page Creator (PC), but it has more facilities for collaboration and change tracking. There are more and better editing tools. It's Wiki-influenced but it feels more like a web page authoring environment than a Wiki. I think you can use it for both.
2. I didn't see that file management (attachments) was any better than PC. I hope I'm missing something. File management in PC is awful.
3. It appears to support Safari, PC doesn't.
4. Like PC you can have multiple sites per domain but you have much more control over access and what becomes public.
5. I haven't figured out the Documents integration yet, not sure it's that well integrated.

I think for most sites it will replace Page Creator. There's no migration yet from existing Page Creator sites however, so today you'd have to recreate all PC work in Google Sites. I hope Google will provide some guidance eventually, I won't be moving anything yet.

I'm glad to see a replacement coming from PC, so this one's good news.

Image drag and drop doesn't work any more with FileMaker Pro

I think I used to drag and drop images from the Finder to FileMaker container field. The Help file says it works.

Except it doesn't.

This post is typical:

Nabble - Filemaker Pro - Talk - Drag and Drop to Container Fields: "I have Leopard and FMP 8.5. Is it my system or is it in general that one cannot drag and drop a jpg from the desktop into a container field? I know I can right click on the container field and insert a picture, but is there an easier way?"

I suspect this broke years ago.

Jeez. Sometimes I think I'm the last software user left on earth. Half the stuff I try is either broken or not usable.

Update 2/28/2008: It sort of works in Filemaker/Windows. Instead of displaying an image, however, it displays an icon that when clicked can show an image. So it might be something that worked in an earlier version of Filemaker but broke a version or two ago. I have read that FM's code base is in pretty bad shape -- despite their big Pascal to C migration of a few years back.

Ejecting a stuck CD: when only open firmware works

Apple has no shame.

If Apple had a sense of shame, CDs would not get stuck inside Macs so often. It's been a problem as long as I remember, but it got much worse when Apple eliminated the old paper-clip manual eject method.

My best guess is that there's some cult around software control of hardware that makes it impossible for Apple engineers to implement non-stick CDs.

Recently I ran into a stuck CD/DVD that failed all the steps in this 2004 MacFixIt article on my 10.4.11 iMac. My comments are in square brackets.

Mini-Tutorial: Ejecting media in Mac OS X: Removing 'stuck' CDs/DVDs - MacFixIt

From time-to-time, removable media (including CDs, DVDs and others) can refuse to eject via the normal Mac OS X methods -- pressing the keyboard eject key; using the Command-E keyboard combination; selecting the item in the Finder and clicking the Eject button next to its name; dragging the item to the trash; or pressing the F12 key. [jf: failed, of course]

... The first and simplest method, if you only want to unmount a single volume on the disk, is to use Disk Utility, located in Applications/Utilities. In Disk Utility, simply select the volume you want to unmount and click Eject. [jf: this usually works, but it failed this time]

... In some cases holding down a connected mouse button at startup will cause a misbehaving optical drive to eject its media. [jf: nope. I have a wireless mouse though, I think this needs a wired mouse. Holding the click key on a MacBook is supposed to work as well]

... If you have a Mac that will not startup properly and has a stuck disc, try booting into Open Firmware by holding down Command, Option, O key and F key during startup. After booting into Open Firmware, type the command eject-cd. [jf: Sort of. "eject-cd" just produced an error message, but "eject cd", after a delay of about 30 seconds, worked.]

Using the Terminal There are two commands that can be used in the Terminal (located in Applications/Utilities) which can be used to force disk ejection:

The first command to try is drutil tray eject. Simply type in this command and press return. [jf: Failed.]

The other method takes a little more work but can work in instances where the first method fails.

1. Type the command drutil list into the Terminal and press return ... [jf: Failed. It never returned.]
2. Use the command drutil tray eject 1.
In the above command, the number "1" should be replaced with whatever drive number you obtained in the first step...

Yech. Only the Open Firmware worked in my situation, but I could have tried connecting my original iMac mouse and booting with the button held down.

I think if one lets Disk Utility sit for a half hour or so it can work even in these most severe situations.

So what was the problem?

One lousy fingerprint on the CD. We washed the CD and it worked perfectly.

Apple is shameless.