mingw/share/doc/gettext/examples/hello-csharp-forms/README

   1 Before you read the hello.cs source code:
   2
   3 Preface about GUI Programming Methodologies
   4 ===========================================
   5
   6 The traditional GUI programming methodology for Windows GUI programmers
   7 is to assemble controls using a GUI builder. These GUI builders
   8 don't have good techniques for determining the size and position of the
   9 controls depending on their contents. Instead, they *hardcode* the
  10 size and positions of the controls in each panel, as fixed numbers,
  11 measured in pixels.
  12
  13 What are the consequences?
  14
  15 1) 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
  23 2) 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
  28 3) 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
  34 Problems 1 and 2 are usually accepted in the Windows programmers
  35 community. (Problem 1 is not fatal, only frustrating. And problem 2
  36 affects only a small proportion of the users; they are simply ignored.)
  37 Problem 3 is "solved" by letting the localization team not only translate
  38 the strings, but also redo the layout of each dialog.
  39
  40 In contrast, the methodology of programmers of the Qt/KDE, Gtk/GNOME,
  41 wxWidgets, AWT, Swing, Tk toolkits is to have the positions and sizes
  42 of 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.
  46 The common technology for this approach is to group related controls
  47 together in containers, and perform size and position propagations
  48 between the controls of the container, the container, the container's
  49 container etc. These computations are performed by so-called
  50 "layout manager" objects.
  51 Other technologies such as global constraint systems (as in Garnet) or
  52 spring-like attachments are not so much in use anymore nowadays.
  53
  54 This programmed-resizing methodology solves the problems 1), 2) and 3).
  55
  56 What are the associated costs and efforts? Taking the programmed-resizing
  57 methodology 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.
  63 In most free software projects, there are at least ca. 5 localizations;
  64 successful projects even have 30 or 50 localizations.
  65 In other words, a program built with hardcoded sizes and positions
  66 cannot afford many localizations, or the effort for localization will
  67 be prohibitively high.
  68
  69 For this reason, we strongly recommend to use the programmed-resizing
  70 methodology. In this example, since the Windows.Forms package lacks
  71 layout manager classes, we compute the layout by hand, through an
  72 override of the OnResize method. For larger programs, we would recommend
  73 to build a few simple layout managers, to get on par with the layout
  74 abilities found in Qt, Swing, etc.
  75 (The layout system of Gtk/GNOME is somewhat particular: It does not
  76 provide the ability to set a preferred alignment on controls like labels.
  77 Instead one uses intermediate containers for the purpose of alignment.)
  78
  79 Acknowledgement: This preface borrows ideas from an article of Luke Plant.
  80
  81 Copyright (C) 2006 Free Software Foundation, Inc.