How should developers cope with so many GUI configuration combinations?

Question

These days, any decent Windows desktop application must perform well and look good under the following conditions:

1. XP and Vista and Windows 7.
2. 32 bit and 64 bit.
3. With and without Themes.
4. With and without Aero.
5. At 96 and 120 and perhaps custom DPIs.
6. One or more monitors (screens).
7. Each OS has its own preferred font.

Oh my! What is a lowly little Windows desktop application developer to do? :(

I'm hoping to get a thread started with suggestions on how to deal with this GUI dilemma.

First off, I'm on Delphi 7.
a) Does Delphi 2010 bring anything new to the table to help with this situation?
b) Should we pick an aftermarket component suite and rely on them to solve all these problems?
c) Should we go with an aftermarket skinning engine?
d) Perhaps a more HTML-type GUI is the way to go. Can we make a relatively complex GUI app with HTML that doesn't require using a browser? (prefer to keep it form based)
e) Should we just knuckle down and code through each one of these scenarios and quit bitching about it?
f) And finally, how in the world are we supposed to test all these conditions?

Lipoma

Tough question! Doesn't eclipse have a perfectly portable system? (windows, linux, mac, every flavor) I'm getting way ahead of myself but I seem to recall it had a Java gui. I'm really unsure of my answer, that's why I make it a comment – Conglobate

Answer 1

For the moment I would like to answer only one question:

f) Use virtual machines and (if possible) automated tests. I know it is a big job to set this up but you will never regret.

Vaclava

Answer 2

For te scaling of your forms on multiple resolutions / DPI sizes: we use DevExpress LayoutControl for that. It makes sure that the controls on your form always align to use the available space, no matter what. And it does a lot more. Have a look at their site.

Buttery

Answer 3

Excellent question.

I've been developing my application for over 10 years, starting with Delphi 2, 3 and then 4 and then staying there and waiting many years to upgrade to Delphi 2009 because Unicode was a must. I'll upgrade again when the 64 bit version comes out.

So I've run the gamut of Operating Systems: Windows 98, Windows 2000, XP, Vista and now 7. Each breaks your UI somewhat, but Delphi has been pretty good about it. At some point in time, you have to decide you cannot support the older OS's anymore, and moving to Unicode finally cut out Windows 98 from my supported list.

Generally, I've found that core Delphi gives you the best UI support. Some third party packages may appear to provide more, but their inconsistencies are worse problems than their benefits might be. Minimize other packages where you can.

The one UI goal I've had is to go for the Windows Vista Logo Program, and more recently the Windows 7 program, and Microsoft does provide a lot of information on what the standards should be that relate the your conditions 1 to 7 in your question. But getting a Delphi program to use a manifest and go through Microsoft's hoops was in the end, not worth the hassle and cost to me, especially since my non-compliant program worked just fine on Vista and 7.

Keeping my program running and keeping the UI looking the same on Windows XP, Vista and 7 when I am developing on a 64-bit Vista machine means I use Microsoft Virtual Machine when I need to. I have been told my program also works on Wine, so that's another test machine.

Now answering your questions:

a) Does Delphi 2010 bring anything new to the table to help with this situation?

Yes. Every version adds new VCL components that have been added to the new OS's. e.g. Windows 7's new UI's have been added.

b) Should we pick an aftermarket component suite and rely on them to solve all these problems?, and c) Should we go with an aftermarket skinning engine?

As I said above, I think its better to do it in Delphi itself than in a 3rd party package.

d) Perhaps a more html type gui is the way to go. Can we make a relatively complex gui app with html that doesn't require using a browser? (prefer to keep it form based)

My application is like a Word Processor with Rich Text. I've looked at HTML-based editor suites and there are a few, but I don't think its the way to go for a desktop application. If you want a web-based application, you would be better off with .NET and Prism.

e) Should we just knuckle down and code through each one of these scenarios and quit bitching about it?

Upgrade to Delphi 2010 first. You'll find Delphi itself will handle most of those situations for you.

f) And finally, how in the world are we supposed to test all these conditions?

Doing it yourself is a big task, even with virtual machines. What you've got to do is have an open Beta and get as many different users in different environments to test your program for you. Then you'll handle all the environments that are most important to your users.

Now, if you think getting user interface compatibility in different Windows environments is tough, just wait until Embarcadero comes up with their version of Delphi that will compile for the Mac. Your current UI worries will seem trivial by comparison to what it will then become.

Teamwork

Answer 4

I, too, am a lowly Windows developer (D7) - much more interested in solving my vertical market application user's problems than coping with M$ foibles.

I cobbled up up a component to deal with all with these issues, plus some more.

As far as I know, all the pieces were in the public domain, and I have credited them where possible.

These are some of the properties:

type TAppEnvironment = class(TComponent)

private

{ Private declarations }

// environment management

FEnvError              : TEnvError;          // environment error code
FEnvErrorMsg           : string;             // environment error message
FEnvLocalComputerName  : string;             // name of the client computer
FEnvCurrentUserName    : string;             // logged-on user
FEnvCurrentUserAdmin   : Boolean;            // is logged-on user Admin?
FEnvProduct            : string;             // windows edition
FEnvProductFlavour     : string;             // windows flavour (Home/Pro)
FEnvBuildNumber        : string;             // windows build number
FEnvServicePack        : string;             // windows service pack
FEnvThemeActive        : Boolean;            // Windows Theme active

// calc using product & theme

FEnvTitleHeight        : integer;            // window title height
FEnvMenuHeight         : integer;            // window menu height
FEnvStatusHeight       : integer;            // window status bar height
FEnvBorderHeight       : integer;            // window border height
FEnvMainHeight         : integer;            // main menu window height
FEnvMainWidth          : integer;            // main menu window width
FEnvHeightAdjust       : integer;            // window height adjust
FEnvWidthAdjust        : integer;            // window width adjust
FEnvLocalPath          : string;             // App exe home folder
FEnvAppFolderName      : string;             // application name less extension
FEnvAppFileVersionStr  : string;             // like 6.0.0.4567
FEnvAppFileVersion     : TFileVersion;       // HiVersion, LoVersion, etc.

And some utilities:

function EnvironmentReady : TEnvError;
function GetLocalComputerName : string;             // network needs this
function GetAppFolderName : string;
function BuildNumber : Integer;
procedure GetFileInfo(const AFileName: string; var RFileInfo: TFileInfo);
function GetLocalPath : string;
procedure getEnvWindowAdjust(bar : TStatusBar);
function setAppFileVersionStr : string;
function GetFileTime(const FileName: string): LongInt;
function initEnvironment : Boolean;
function exitEnvironment : Boolean;
function AlreadyRunning : Boolean;
function specialBuild : Boolean;

I have a function to size each form correctly, using FEnvTitleHeight, etc.

All the dumb user paths are also generated, depending on Windows version.

I have no clue as to how to manage the process, but if people want, I will toss the whole thing into the pot - so that the masters can work it over.

Injector

Where is a good place? Is it OK to just post text - pieces or all at a time? I still have to remove some security code from it & fix the comments. Later today, perhaps. – Injector

Answer 5

Delphi 2009 brought in support for theming (it is an application level setting). When you run a Delphi 2009 or above application in Vista / Windows 7, it changes the message boxes to TaskDialogs, so you get some UI improvements for free.

We had a bit of a struggle porting to Delphi 2009, and Unicode, but that was a 'technical debt' that we had to pay at some point.

Hope this helps.

Prison

Delphi added Windows theme support in Delphi 7, which has improved in subsequent versions. – Versieversification

Yeas, via the XPManifest, but then it was taken out and D2007 have a much better system. – Prison

Answer 6

Delphi makes that fairly easy, but in the end you'll have run your software on all Windows versions and visually check that everything looks fine. Automated test are great to test the functionality, but the cosmetics can be checked visually only.

Submergible

That is only partly true: you only can check if a layout is Ok by looking at it, but when you did this decision once you can use automated tests to check if the current layout is still the same. If it is different you may be noticed and still can have a look, but if it is the same you don't need to look at it at all. – Vaclava

Answer 7

• Delphi 2010 brings native Unicode support.
• Delphi 2010 brings Windows Vista/Seven controls.
• There is no 64 bit Delphi compiler for the moment beeing.
• You should'nt have any problem to handle dpi and monitor count questions with Delphi 7

Bruell

Delphi isn't able to handle different system fonts and DPI settings well, it uses pixel-based layouts and lacks a proper layout manager. It also hard-codes fonts in the DFM files. – Deafening

Here is probaly a solution to the dpi question : gerixsoft.com/blog/delphi/large-fonts – Bruell