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