NameDateSize

..22-Dec-201640

autoclean.shH A D12-Jan-2016836

autogen.shH A D12-Jan-20161.7 KiB

BUGSH A D12-Jan-2016156

configure.acH A D12-Jan-20161.5 KiB

hello.csH A D12-Jan-20162.8 KiB

INSTALLH A D12-Jan-2016232

m4/H22-Dec-20164

Makefile.amH A D12-Jan-20162 KiB

po/H22-Dec-201632

READMEH A D12-Jan-20164 KiB

README

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