1Before you read the hello.cs source code: 2 3Preface about GUI Programming Methodologies 4=========================================== 5 6The traditional GUI programming methodology for Windows GUI programmers 7is to assemble controls using a GUI builder. These GUI builders 8don't have good techniques for determining the size and position of the 9controls depending on their contents. Instead, they *hardcode* the 10size and positions of the controls in each panel, as fixed numbers, 11measured in pixels. 12 13What are the consequences? 14 151) Consequences for all users: 16 Such panels would not look nice when the user resizes them. So the 17 programmer simply makes the dialogs non-resizable. When such a 18 panel then contains a scrollable list of items, with 100 items and 19 a scroll window of 5 items, a user's normal reaction is to enlarge 20 the dialog, to see more items. But the dialog is not resizable! 21 Frustration. 22 232) Consequences for disabled users: 24 Some users need bigger fonts for working comfortably. Guess what 25 happens when the user changes the size of the default system font? 26 Many labels in dialogs are truncated. 27 283) Consequences for internationalization: 29 The translation of a term or label in another language often needs 30 more screen space. For example, Japanese translations often are 30% 31 longer than the original English label. Therefore, if only the strings 32 of a dialog are localized, many labels are truncated. 33 34Problems 1 and 2 are usually accepted in the Windows programmers 35community. (Problem 1 is not fatal, only frustrating. And problem 2 36affects only a small proportion of the users; they are simply ignored.) 37Problem 3 is "solved" by letting the localization team not only translate 38the strings, but also redo the layout of each dialog. 39 40In contrast, the methodology of programmers of the Qt/KDE, Gtk/GNOME, 41wxWidgets, AWT, Swing, Tk toolkits is to have the positions and sizes 42of controls determined at runtime, according to 43 - the needs of the control itself, 44 - the needs of the other controls in the panel, 45 - the available panel size, given by the user through resizing. 46The common technology for this approach is to group related controls 47together in containers, and perform size and position propagations 48between the controls of the container, the container, the container's 49container etc. These computations are performed by so-called 50"layout manager" objects. 51Other technologies such as global constraint systems (as in Garnet) or 52spring-like attachments are not so much in use anymore nowadays. 53 54This programmed-resizing methodology solves the problems 1), 2) and 3). 55 56What are the associated costs and efforts? Taking the programmed-resizing 57methodology as baseline, the hardcoded sizes and positions approach has 58 - the advantage that the programmer saves about 1/3 of the GUI 59 programming work (namely choosing the layout managers and setting 60 alignment hints), 61 - the drawback that each localization team has much more work, namely 62 to rearrange the controls in the panel. 63In most free software projects, there are at least ca. 5 localizations; 64successful projects even have 30 or 50 localizations. 65In other words, a program built with hardcoded sizes and positions 66cannot afford many localizations, or the effort for localization will 67be prohibitively high. 68 69For this reason, we strongly recommend to use the programmed-resizing 70methodology. In this example, since the Windows.Forms package lacks 71layout manager classes, we compute the layout by hand, through an 72override of the OnResize method. For larger programs, we would recommend 73to build a few simple layout managers, to get on par with the layout 74abilities found in Qt, Swing, etc. 75(The layout system of Gtk/GNOME is somewhat particular: It does not 76provide the ability to set a preferred alignment on controls like labels. 77Instead one uses intermediate containers for the purpose of alignment.) 78 79Acknowledgement: This preface borrows ideas from an article of Luke Plant. 80 81Copyright (C) 2006 Free Software Foundation, Inc. 82