My Apple AV composite cable no longer works with my 3G iPhone.

If you have an Apple AV cable, you may want to see it if still works with your iPhone after the 2.1 update. I just posted this on Apple's discussion list:

Apple - Support - Discussions - My Apple AV composite cable no longer ...

I purchased an Apple composite AV cable from my local Apple store shortly after I bought my 3G iPhone.

It worked then.

I haven't used it much, but this morning I tried it again.

This time I got a message something like this:

"This accessory was not made to work with the iPhone. Would you like to turn on Airplane mode to reduce interference?"

It works with my older 3rd generation iPod.

This isn't an after-market cable. I bought it (yes, $50) at an Apple store because I knew Apple had shut out non-Apple connectors with the new generation devices.

I've seen various messages about failures of the AV cables after the 2.1 update. Most refer to aftermarket cables, or Apple cables purchased indirectly (may be counterfeit).

Has anyone else run into this?

I suppose I'll have to go back to the Apple Store with the cable and receipt and see what they can do about it.

I'll update this post with what I hear from my Apple store. If it turns out Apple deliberately broke their own cables that worked with iPhone 2.0 ...

Update: I read a post that suggests the connectors are a funny fit with the new iPhone -- that they may not always contact fully and this produces the message. I'll inspect closely and try again.

Update: Yes, it's the cable. If it's not fully seated you get this error. The old iPod connector used a locking connection with a positive click, the AV cable uses a lockless connector that differs from the newer lockless iPhone connector. I suspect the AV cable connector was a transitional design that may have more connectivity issues.

Bento 2: Modest good news, lots of bad news, slow as spit

The good news about Bento 2 is that it gives Leopard users access to their Address Book, Calendar and Tasks. Mail too, I think. That's probably worth $50 for me, especially if the current version FileMaker can't access these stores (I use an old version of FMP, haven't yet seen a good reason to upgrade.)

The bad news is the queries (called smart collections) can't be nested.

So you can define a query, but you can't reference it in a second query.

iTunes allows nested queries, I use them extensively. iPhoto doesn't, I miss 'em.

Some aspects of databases are hard to understand, but iTunes shows that regular users can learn to appreciate nested queries.

So, unfortunate omission.

I'm going to see if I can use Bento to help merge my Gmail and personal address books. If it works for that, I'll buy.

Even without the nested queries.

Update: I watched the videos. You create relationships by drag and dropping records. The 1 many relationship is seen through a "portal" window in a Bento form. Problem is, I don't see how you create a relationship by, say, relating all persons common last names in a single view. Bento would be more interesting if it were integrated with FileMaker, so we could use Bento to access iCal and similar stores but use FM to do more useful operations.

Update: There's no FileMaker Pro integration. The two are completely separate products using unrelated data stores (SQLite for Bento, as in /Users/account name/Application Support/Bento/bento.bentodb/Contents/Resources/Database). You can't link from a FileMaker Pro database into a Bento Library. Yuck. The only way out of this would be if someone figures out a way to use a more powerful SQLite app to manipulate Bento data. I'll watch for that.

This Nov 2007 Daring Fireball post has some more leads for understanding Bento.

Actual Technologies sells a connector that may allow a FMPro app to access SQLite data, may be read-only.

Bento is apple scriptable ...

Update 11/2/2008: Still in my trial period, I tried using Bento to enter several items quickly into my large iCal (several calendars, total 6,300 events). This is a trivial task with Outlook and its multiple views, but it's not supported in iCal.

Opening the Bento database, which includes the iCal tables, took minutes. Adding a single record took a minute. Type lag was severe.

Bento operations were excruciatingly slow on my single-core G5 iMac; manipulating my calendar reliably pegged the CPU. I was surprised how crude the UI was for specifying a calendar in a filtered view; I expected a drop down list but instead had to type the calendar name.

When doing data entry the type lag was gruesome. Yes, in a bloody database app there's type lag. It ain't doing fancy type layout, where the heck is the lag coming from?

When viewing a "collection" you can't create a new record. Lame.

This is an achingly inefficient load of software. It's miserable.

Deleting multiple iPhone camera roll pictures

It's odd that Apple hasn't fixed this bit of missing functionality; on OS X there's no obvious way to mass delete pictures taken with the iPhone camera!

In XP, ironically, it's very simple. XP mounts the camera store as a drive. You can't write to it (I tried of course), but you can select and delete.

In OS X most people recommend using Image Capture to "download and delete".

This tip points out you don't really need to download:

macosxhints.com - Delete multiple photos from the iPhone's Camera Roll

... Launch Image Capture and hit the Download Some button, and you are then free to roam the camera roll, selecting and deleting multiple images...

In case this isn't clear ... Launch Image Capture and click "download some", but you don't need to download any. Select all, then click the "delete" icon in the toolbar. All images are removed.

This is another odd bit of missing iPhone functionality! Of course it's not as critical as the missing calendar API, missing search functionality, the missing cut/copy paste function, the missing tethering tool, ...

iPhoto library sharing - the official Apple method

Apple's kb has an article on Sharing iPhoto libraries among multiple users.

Wild, it's more like what one would read on a geek site.

Turns out it can be done more or less safely. Problem is you need an external drive that ignores permissions -- or you can use a disk image in the shared item folder.

Is this some kind of sign that iLife '09 will support multiple iPhoto Library merges?

Ok, so I'm grasping at straws.

Update 3/9/09: The article was revised 1/12/09. I think they added a disk image option to turn off permission checking. If you go the disk image route remember that the standard disk image is hell on backups. Every time you change one byte in a 40GB Library the whole image has to be backed up. Sparse bundle images mitigate this problem, but Retrospect doesn't back up sparse bundle image backup properly (Time Machine does).

I might try this in a folder where my wife and I both have read/write privileges, though I'm concerned Apple didn't mention this obvious solution. I'll want to verify that this actually happens:

Keep in mind that while one user is viewing this library from iPhoto, another user will not be able to open this library at the same time. Instead, an alert message appears indicating that the library is already in use. You will need to quit iPhoto from the other user account before the next user will be able to view or edit this library.

Update 3/9/09b: Ok, I see the problem. It has to do with the way OS X (BSD Unix) manages permissions and it's a deep problem. Even if I create a shared folder and move my Pictures there, each file inside the "Library" (package) is still mine alone. Even if I change permissions on every file so "Parents" can edit them, newly added images will still get one or the other user's permissions. Yech!!

So to share a Photo library between multiple users you really do need to use something that ignores permissions -- or you need a future version of OS X -- or you need to use the Mac OS X Hints ACL hack.

Update 3/10/09: No changes with iPhoto. As I wrote on this Discussion thread, I think the problem is deeply embedded in the design of OS X (BSD Unix?) file sharing:

I don't think this is something that iPhoto can fix, it's really more of an OS problem. I THINK that the problem goes something like this:

1. OS X assigns new files permissions associated with their owner.
2. OS X allows only one owner per file.

So even if one set all the permissions on thousands of Library files to a multi-user group, the first time someone added new items to the Library there would again be inaccessible files.

Using an external drive or a disk image works because one can then ignore permissions, thereby eliminating a vast amount of security as well!

It's really a fairly deep OS problem. I wonder if Snow Leopard tries an alternative approach. I think XP file sharing doesn't have this particular problem, but I can't say for sure.

Interestingly the Apple kb article seems to imply that images ignore permissions. Thinking about how they're used, I bet that's true. Oddly enough, I can't find good google hits on this.

Alas, I can't go the sparsebundle route because my backup software (Retrospect) needs an update to manage these appropriately.

Update 3/19/09: I'm told Retrospect treats the Sparse Bundle as just another package. I'm doing some testing; after copying an iPhoto Library to the Sparse bundle I have:

Original iPhoto Library: 3.7 GB
Sparse Image Bundle version: 3.8 GB in 488 8MB bands (view package contents)

iPhoto editing in the Sparse bundle library can be hard on backups. I changed a rating on a single image, and five bands were revised (40MB of dat to backup).

Now I need to see how Retrospect behaves.

Incidentally, even though file privileges are ignored on this image, they still exist. So if you let multiple people work on Library, then move it to drive where privileges are NOT ignored, won't the Library be trashed until all privileges are corrected?

This feels like a nasty hack to work around a really bad file system design.

Update 4/9/09: Supposedly Apple has secretly fixed this in iLive '09!

Update 5/6/09: I updated another post with information about Retrospect and sparse bundles based on informed comments. It doesn't look good to me.

Using FrontRow for visually impaired OS X users

Front Row is designed for remote control at a distance. So the UI is pretty good for someone with poor vision, and it's much simpler than iTunes.

On the other hand, the remote is only intuitive to computer geeks. It's also difficult for someone with motor problems to use; the menu button, for example, is flush.

You can improve the menu button by putting fuzzy side velcro tape on it, but an alternative is to use the undocumented Front Row Key commands.

Undocumented, save for a generous blogger who compiled a list. See his site for the full list, here's my annotated version of an excerpt of it. Note that I used Keyboard Preferences to change the activation/quit key to F13. Unfortunately the F13 key doesn't behave exactly like the Menu button -- it starts and quits rather than moves in and out of menus.

rgbdream.com - Front Row Key Commands

Activation

Enter Front Row	F13
Quit Front Row	F13 (actually any key not used by FR will exit)

Menu actions

Up	Up-arrow
Down	Down-arrow
Select	Space
Previous menu	Escape

Playback controls

Play/Pause	Space
Rewind	Left-arrow
Fast-forward	Right-arrow
Previous track	Command + Left-arrow
Next track	Command + Right-arrow

Volume

Volume Up	Command + Up-arrow
Volume Down	Command + Down-arrow

Depending on your context sometimes the arrow keys also navigate menus and control volume.

I'm experimenting to figure out the right balance of use of a modified remote and the keyboard. I think the remove may win overall, but using the arrow and enter keys might be useful. You can use the kb volume keys to change volume.

MobileMe - Remote system control would make it useful

Apple's MobileMe is monumentally uninteresting -- less useful than .Mac.

Actually, it's worse than that. It's inferior to Google Apps, but since MobileMe is an Apple revenue stream they're incented to discourage Google Apps.

This is unfortunate, because if Apple made some modest changes to OS X 10.5 and MobileMe I'd buy a family package of both.

I want a remote system control option built into MobileMe. In particular I want to have full control of my mother's Mac Mini at all times -- without requiring her to do anything. (See also.)

Apple has all the pieces for this to work; even their toy VNC based remote control would be suffice.

[I first drafted this for .Mac in 2005. Found it while doing some cleanup; it's still true today.]

Toggle grayscale display on OS X with this AppleScript

I was looking for something that would give my mother a few more months of computer use. The OS X grayscale accessibility option looked interesting, but there's no keyboard shortcut for this option.

I thought I could record an AppleScript shortcut, but the accessibility pane is not scriptable. (Apple had, I think, a reasonable accessibility record with Mac Classic, but they tossed that out with OS X. They've been notably half-hearted for years, but some recent threats from Massachusetts may inspire future improvements.).

Apple recommends using System Events, but that's way beyond my limited AppleScript skills. I've made several stabs at figuring out AppleScript, but the damned language just annoys me. I wish they'd deprecate the original and adopt Python's syntax, scoping, etc.

But I digress.

Baltwo, a generous Apple forum poster [1], has written a post with the AppleScript System Events script I was looking for. It works in 10.5.5 ...

Apple - Support - Discussions - Keyboard shortcut to switch between ...

tell application 'System Preferences' to activate
delay 1
tell application 'System Events'
tell process 'System Preferences'
click the menu item 'Universal Access' of the menu 'View' of menu bar 1
click the radio button 'Seeing' of the first tab group of window 'Universal Access'
click the checkbox 'Use grayscale' of tab group 1 of window 'Universal Access'
end tell
end tell
tell application 'System Preferences' to quit"

The script, of course, will break with significant UI changes to the Universal Access pain. It works for now, I'll test it out with 10.4.11 though I think some of the System Events scripting might require 10.5.

Apple has greatly improved their AppleScript support site by the way. I've thought for years that AppleScript would go the way of OS X Services, but it continues on.

[1] You can now "subscribe" to users, and I've "subscribed" to his posts. I wonder sometimes if these are real people, or pseudonyms for Apple employees. written a very large number of forum posts.