You Can't Beat the Pyramids

A sidebar on toolbars for the coming ACP interim release.

Get It Try It

ORANGE WALK TOWN (Rixstep) — This update applies to all versions. It's made available now for 10.7+ and 10.13-10.14. 10.12 will follow.

It's important you read this before proceeding and downloading. If you do not, it's no great calamity, as your ACP Framework will be OK anyway.

But this update does require updating the ACP Framework.

A Sidebar on Toolbars

What's been done?

Generally: we're gradually introducing a new technology, to be used across the board. This has to do with toolbars only. You'll see the difference as soon as you run one of the eight applications affected.

Note that the glyphs (images) in the toolbars are not static. They are what is already being used. These will change over time as we find suitable replacements. What we're after is the 'black on white' minimalist approach currently being pimped by Apple. We like this approach.

Toolbars should be used and not seen, one might say. They benefit - and you benefit - if they're unobtrusive, don't grab your attention, and are only noticeable when you need them.

An History of Toolbars

There was a time when no one had toolbars. Windows didn't have them. They had only 'toolboxes'. These were 'floaters' with 28x28 images. There was nothing programmatic about them. All their images - six states for each - were full bitmaps.

Borland invented the 'speedbar'. This was programmatic. It's necessary to give visual feedback on a button state - to show when a command is not available.

Borland did this by providing a 'dither' bitmap that gave buttons a 'faded' look when buttons were disabled.

Kyle Marsh and Wes Cherry (of the Excel team) were called to the rescue. They were tasked with finding a way to use Microsoft's 'toolbox' idea programmatically to make toolbars. They did an excellent job, but with two caveats.

1. No more 'dark red'.
2. The algorithms only worked correctly with grey images.

(Glyphs were incidentally reduced from 28x28 to 24x24.)

Using colours made the glyphs 'blotchy'. But Kyle and Wes did achieve the great 'chiseled' effect used to depict a disabled button.

(This was done by superimposing images 1x1 to the right and down.)

Ramping up to Windows 95, Microsoft were ready to unveil this technology and make it available in their API. 'Missionaries' from Redmond toured the globe and warned people that this technology would not work well with coloured images. They explained that colour in glyphs was 'childish' anyway.

Microsoft were pressured to put colour in their toolbars, and happily discovered that some variants on yellow worked OK. They famously had a yellow 'open' glyph for years as their only example of colour in a toolbar.

Microsoft were put under more pressure, and gradually opened the floodgates completely. But this meant scrapping the use of a 'disabled' button. Microsoft solved this by offering a 'beep' instead. No visible change at all.

Radsoft found a way around this where Microsoft had not, and introduced this technology in their XPT.

Chesapeake Drive

NeXT never used toolbars. They didn't need them. Their menus were detachable. You could rip off a piece of a menu and have it float anywhere on screen. Anywhere. (Think about it.)

(Menus emanated from the left of the screen, a much more practical and intelligent solution.)

By the time NeXT conquered Apple, Microsoft toolbars had gone completely wild. It was possible to fill a full-screen Office app with toolbars, with no space left for editing. As Apple took on NeXT code, toolbar technology of a sort was introduced. The technology was programmatic, based on callbacks. It's what's been used in the ACP since 'Day One'.

Rixstep's ACP also goes one step further: no images used in any of the 'Great 8' are found on disk. Their representation is in 'text-only', making application launch times extremely fast. (And no, it's not SVG, in case you were wondering. All ACP images are found in a single file, loaded once - and only once - by the ACP Framework. Address space mapping...)

At Apple, subclassing individual toolbar items came along, for things like search fields. Then somebody found a cute look with a certain type of NSButton (which inherits from NSView). There are a few minimal caveats but they're easily dealt with.

'By the time NeXT conquered Apple, Microsoft toolbars had gone completely wild. It was possible to fill a full-screen Office app with toolbars, with no space left for editing.'

Then Apple invented the 'asset catalog'. This is not as efficient as the ACP method, but is a vast improvement over separate image files. (Median HDD access times...)

Rixstep's new Tracker uses the asset catalog in a transitional phase.

Apple ISV developers started using more and more time in IB to 'freeze-dry' toolbars (and toolbar images) into window NIBs. The unwieldy IB interface makes this possible, but it's a lot of work not at all related to programming, or the actual task at hand. Mostly clicks.

But if it can be 'freeze-dried' in a NIB then it can certainly be done - with even greater ease - programmatically, although there are precious few examples available. Yet it's only a matter of analysing what's going on 'under the bonnet' and replicating it in code.

Thus our current 'transitional' look. Once again, save for Tracker which deliberately remains 'as is' as a yardstick, all details are buried in the ACP Framework. No images on disk.

(Client binaries on an average are 32 bytes smaller, for using this new technology.)

The goal of good programming is to make work easier. The goal of commercial programming is to increase revenues. The goal of commercial programming is to take the eminently simple and make it impossibly complex. The goal of real programming is to reduce the impossibly complex to eminently simple (and thereby elegant).

You can't beat the pyramids.

PS. The best interfaces are self-evident. The best applications don't need an instruction manual. NeXT's original tools win hands-down. Apple's current Xcode doesn't.

About Rixstep

Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.

Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.

All Content and Software Copyright © Rixstep. All Rights Reserved.