From: Bruno Haible Date: Mon, 27 Mar 2006 11:58:51 +0000 (+0000) Subject: Methodology explanations. X-Git-Tag: v0.15~276 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=7d11c8296fedf49c3746f53c3c4f7f0d18964302;p=thirdparty%2Fgettext.git Methodology explanations. --- diff --git a/gettext-tools/examples/hello-csharp-forms/README b/gettext-tools/examples/hello-csharp-forms/README new file mode 100644 index 000000000..5756710df --- /dev/null +++ b/gettext-tools/examples/hello-csharp-forms/README @@ -0,0 +1,81 @@ +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.