1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
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.
|
