Structure and Interpretation of Computer Programmers

I make it easier and faster for you to write high-quality software.

Thursday, April 10, 2008

Come back, purple button, all is forgiven!

As a great philosopher once wrote: don’t it always seem to go, that you don’t know what you got ’til it’s gone? Previews of Mac OS X had a user interface feature, known by all who saw it as the Purple Button. Look at this screenshot from System Preferences:

The boiled sweet on the top-right of the window would go purple, hence the name. Clicking on it activated a single-window mode. All documents except the one that you were working on would be minimised into the Dock, and switching between them would minimise the earlier one before restoring the newly-focused document. Of course, the problem with this in the developer previews/public beta which rendered it unusable were performance-related. The “lickable” eye-candy in Aqua was ambitious even on the top-end G4 systems available at the time, and so time spent in the Genie or Scale effects was really noticable. Add to that the effect of applications being slow enough not to update their views in time – the System Preferences application you can see above is a Cocoa-Java app, and back then the JVM wasn’t amazing for performance – and you have a really sucky single-window experience.

On the other hand, it’s really bloody useful. Look at apps like WriteRoom or GLTerminal, which go out of their way to get rid of all that other clutter. Or Spaces (or CDE virtual desktops, WindowMaker virtual desktops… you get the idea), also designed to let you forget all those other apps are there. Well, spaces is quite nice (and a little more flexible than purple button was), but playing spaces ping-pong tends to make me a bit seasick. Not to mention the time it wastes being about as great as the unperformant purple button switching…so please, purple button, come back!

Some environments provided the same user experience out of a lack of choice – for instance, OZ couldn’t show more than one application if it wanted to, and certainly running more than one at once was out of the question (it would simulate multi-tasking by suspending background tasks).

posted by Graham Lee at 18:56  

Saturday, January 26, 2008

Permissions whee!

As in any good mystery, the question is who done it? MacNN reports a flaw in Tiger, Leopard in which an authenticated copy operation gives the destination files (the copies) the ownership of the logged-in user, not of the name they used to authenticate. The question is, which user did the copy?

Let’s say there’s a system with Alice Administrator and Richard Regular-User. Richard downloads a new application from the intarwebs, and wants to put it in /Applications (though why? Why can’t he just put it in ~/Applications like a good little user? Never mind). The thing is, he doesn’t have the right to do that. Finder presents him with an authentication dialogue, and no matter how many times he enters his username and password correctly, he can’t acquire that right. However, he sees Alice walking past in the corridor and asks her to enter her admin credentials. For whatever reason, she agrees – now Alice has authenticated and Alice has acquired the right to copy the files. So even though Richard requested the copy, it was actually Alice who performed it. Therefore Alice created the files at the destination, so they should be owned by Alice.

The only thing which muddies the waters (and leads to the conflict of convenience vs. security which is described in that article) is that in many, or indeed most, cases on OS X where this will arise, Alice and Richard are actually the same person – Sammy the Single (Security-conscious, hence separating their use of the system into regular and admin accounts) User. It’s a convenience that as Richard wanted the files copied, Richard now owns the copy – but this defeats the point of Richard existing, which is that Sammy doesn’t want to be able to change /Applications without being warned.

Interestingly the same question doesn’t get asked of the sudo command – it’s clear that if I type sudo ditto Foobar.app /Applications/Foobar.app it’s the super-user who does the work.

posted by Graham Lee at 01:04  

Powered by WordPress