Radsoft
 About | Buy | News | Products | Rants | Search | Security
Home » Resources » Red Hat Diaries

Red Hat Diaries/0047

Apples & Lemons

One of the areas where Apple really shines (and Microsoft really stinks) is in the creation of dialogs - special windows with a predefined appearance. Windows can be created on the fly, with embedded (child) controls thrown in afterwards through code snippets, but complex constellations are more easily dealt with through a so-called dialog script. And it's in getting this 'dialog script' - the dialog itself - to look good that one begins to see the enormous difference between the one platform and the other.

Microsoft's resource editor, used to design dialogs, is one of the most lacklustre products on the market today, but unfortunately it's mostly alone, Microsoft having driven the competition out of business not by providing superior software, but by strict monopoly bullying tactics. Borland's Resource Workshop was an awesome application; but Microsoft finally decided they would be better off without Borland around, and the rest - despite Borland surviving as Inprise - is history: Microsoft has no 'real' competition today.

The resource editor is incapable of positioning dialogs; all that can be done is determine their size. You don't want all dialogs to come up in the x,y origin of the client area, but Microsoft offers you no way of setting this. You have to go into the text of the dialog script (it's only text anyway) and set it.

Further, Microsoft uses a 'dialog unit' coordinate system for its dialogs. These dialog units are calculated from the so-called 'dialog base units' which are determined by the metrics of the default 'System' font, otherwise rarely used today. Units on the x axis are not the same as units on the y axis, and conversions into screen pixels are lugubrious. What's more, dialog units change in value as the font used for the dialog changes. This also correctly implies that Microsoft cannot admit of a dialog using more than one font. If you want more than one font in a dialog, you have to implement this programmatically.

And although Microsoft definitely has design rules for dialogs, all the calculations for the placement of controls have to be done manually. Dialogs are to have a 'margin' all around of 7 dialog units; there is to be 6 units between controls and 8 units between the controls and the push buttons (such as OK and Cancel). Further, related push buttons are to be placed 4 to 5 units apart, while unrelated push buttons are to be placed another unit apart. All this has to be calculated manually.

Typically the dialog developer will calculate the x offset of a control, add to that the x extent of the control, add to that 8 dialog units etc. to determine where the push buttons should be located. Then the dialog developer will add the x coordinate of the push buttons, add to that their extent, and add to that 7 more dialog units to arrive at the width of the dialog in general.

It's a lot of calculation, for each and every control in each and every dialog ever created.

On the Apple side with NextStep all of this is automatic. The NS Interface Builder automatically figures out what you are trying to place where, and creates small thin light blue lines to guide you. As you move the control into position, these lines become visible; all you have to do is align your control along them.

Further, Apple lets you put text into a dialog with any font you choose. Several standard text sizes are provided for so-called 'static' controls - it's just to choose between them.

Apple 'dialogs' are also, thanks to Interface Builder and the NextStep environment, highly 'intelligent': it is possible to create entire applications without writing any code at all - all the logic is contained in the dialog script itself.

It's like apples and lemons.

Click here »

About | Buy | News | Products | Rants | Search | Security
Copyright © Radsoft. All rights reserved.