That’s the way my graphical user interface (GUI) meanwhile looks. By means of seemingly unending patience I hunted down a plethora of elements and gradually understood how the whole thing gets composed. First I tried to substitute everything I wanted to use by my own elements and just jettison the rest. This works for the standard applications coming with Windows, but seldomly with third party applications. Although the surfaces of lots of those are especially designed to be used with Windows, they do not readily adopt my changes, but stubbornly display elements of their own choice and looks. I found out that disabling or even deleting parts of the elements is not a good idea, because—I guess this is due to Microsoft’s visual style policy—the interface designers reach down into the elements storage’s every cellar’s very last corner in order to find something that suits their purposes or vision. For example you force the menu bar to be displayed in a certain way, launch some application, and find out that it doesn’t comply. A little research unearths the fact that the particular menu bar does not use the menu bar definitions, but e.g. the systems button definitions. And so on. Till now I can not fathom where the hell the looks of Star Office’s menu bar are stored … whatever I do, it just remains an ugly grey—maybe it is located within Star Office itself … gotta resource hack that. All in all, the organisation of the elements for the Windows GUI seems to me a complete chaos. There of course is order and logic—desperately needed to make the whole thing run, and indeed runs, quite flawless—but the logical rule set for interlinking the different elements could be a lot more simple, if there would be way less redundant elements. Mind, I am really not sure if I have understood everything correctly, but let us take the close, restore, minimize, and maximize buttons to the top right of every window as an example. The functionality and interlinking logic is perfect. But there are several ways this buttons are generated. Firstly there are graphics files containing the backgrounds and signs of every button in every state they can adopt (normal, pressed, mouse over, etc.). Secondly there are graphics files only displaying the button backgrounds in every state. To make this empty buttons meaningful, a “glyph”—a graphical sign like e.g an arrow—has to be overlayed. Fine idea. That way you could have only one graphics file for describing buttons (containing every state a button can assume) for the whole GUI. Which state-frames are used then are defined at every instance of usage, and the function visually gets defined by an overlay glyph. But both strategies—”complete” graphics file and button background plus glyph—are used by the Windows GUI and get merrily mixed up. The hell, why? Well, I can imagine why. From Windows version to Windows version new features simply are added on top of the old stuff, and a real clean up is never done. But, I have to confess, it is tremendous fun to mess around with that chaos and make it your very own chaos.