Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Learning Curve » Developers Workshop

Cosmetic Bugs Persist in 10.6 NSToolbar

They're not going away soon.


Get It

Try It

The Apple developers Scott left behind introduced two cosmetic bugs in the AppKit class NSToolbar for OS X 10.6. They'll probably be around for a while.

OS X 10.6 is a faster system. It runs in 64-bit - and with more modern Apple hardware, will boot the kernel as 64-bit as well. Performance is generally way up.

But two cosmetic bugs were introduced into the NSToolbar class code and after five iterations of 10.6 they show no signs of being fixed.

√ Toolbar initialisation. Applications respond to callbacks from system code to configure and initialise their toolbars. One of the more important bits of information sent back to the system is the initial state of a toolbar button - enabled or disabled.

Only one image need be sent to the system - that of the enabled glyph for the toolbar button. The system renders the button as enabled or disabled on its own.

The system's toolbar configuration sheet is supposed to display all possible toolbar items (as well as a default toolbar) to give the user the opportunity to reconfigure the toolbar (or revert to the default).

Previous versions of OS X handled this correctly. The images used in the toolbar configuration sheet are cached from the callback sequence the NSToolbar class initiates to configure the toolbar.

The NSToolbar class for 10.6 somehow takes the images from the initial state of each image, enabled or disabled.

There's a reason for letting client applications specify the starting state of a button: developers don't want 'flash' on screen as their applications come up. This has always been an annoying experience for users. It's therefore been good practice to set the startup state of a toolbar button (if possible) according to what startup conditions will be.

Not all ISVs bother with this; some ISVs do.



Somehow the NSToolbar code for initialisation has been moved around; the results haven't been good. 10.6 is faster than previous versions of 10.6, but the way the NSToolbar code works in 10.6 is different from all previous versions of 10.6, it's flawed and incorrect, and it denigrates the user experience.

The workaround: ISVs now have to set all their toolbar items to be initially enabled - otherwise the icons for these items will show up incorrectly on the toolbar configuration sheet.

Users can use a workaround if they care: enable (through use of the program) the disabled buttons, drag them from the toolbar, then drag them back from the configuration sheet again. This forces the flawed NSToolbar code to update its cache. Unfortunately this doesn't persist between sessions - the flaw will return again on next startup. A real bother for little gain.

√ Snail speed validation. Toolbar items generally get validated (updated) through the application run loop. This has always been enough for some ISVs but others take the time and effort to force a validation when the application user should expect feedback immediately on actions taken.

Starting with 10.6, this validation sometimes takes ages. It has nothing to do with run loops - it's just sloppy code that once again adversely affects the user experience.

There's no workaround for developers: this part of the system code is totally beyond their control.

Can't Scott spare a few of his iP* developers for an afternoon to fix these bugs?

Postscript: Flaw in 10.6 Screenshot Design

There's a flaw in the screenshot design. The idea with the new name generation scheme is to ensure the generated file names are unique and to keep them in sorting order. Use of a 12 hour clock with 'AM' and 'PM' of course completely undermines this goal.

Ask Scott's boys for help.

See Also
Developers Workshop: Mail.app Orphans Redux

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.