mirror of
https://https.git.savannah.gnu.org/git/gettext.git
synced 2026-01-31 03:45:49 +00:00
82 lines
4.0 KiB
Plaintext
82 lines
4.0 KiB
Plaintext
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.
|