Re: About layouts

[Gus Koppel <gtk spamkiller bytechase cx>]

Fernando Apesteguía wrote:

> First of all, thanks for your suggestions.
>
> Actually my app. uses a static layout and the GtkLabels inside this, don't
> grown when the text becomes longer. The same GtkLabel behaves ok if it is
> inside a GtkTable. So I think I will change the static container.

By "static container" you probably refer to a GtkFixed container? Yes,
you should change that. GtkFixed (for static layout) should be
considered pretty deprecated. Obviously a static layout container
contradicts the concept of dynamic (re)layout. And the native concept of
GTK+ GUI design and layout is highly dynamic.

GtkFixed is mostly a courtesy for programmers from other GUIs, like the
MS-Windows or QT ones, where static layout is the default and has a long
history. Some of them tend to have problems getting used to more modern
GUI layout and keep asking "how do I specify X and Y coordinates of my
buttons?" To modern GUI layout processes, this question simply doesn't
apply any more.

Dynamic GUI design by using dynamic GTK+ containers is the modern way of
flexible GUI design. This way, widgets don't have any sort of absolute X
or Y coordinates nor static widths or heights. Instead, only the basic
layout (their positions, sizes and optionally gaps relative to each
other) are specified using layout containers. At runtime GTK+ then
dynamically calculates the absolute positions and sizes of widgets
within windows. This way also honors themability better than static
layouts, since different themes may use different font sizes and hence
require different dimensions for all sorts of texts.

I think except when you're dealing with many bitmaps in a dialog and
their pixel-wise layout is really important (which it usually isn't):
don't use GtkFixed at all!

> My app uses a menu bar and a GtkNotebook. In every tab, I have several
> GtkLabels and ProgressBars. So if I choose to use non-static containers I
> think I'll need two or three GtkTables for each tab.I have three tabs now
> but it is expected to have at least five.

If their layout is supposed to be aligned (as sketched in my previous
posting) then you would need just one GtkTable for each tab. For more
sophisticated layouts, more layout containers would be needed, indeed.

> If I change the static layout + label for a deeper containers hierarchy
> (three levels for example)... will I have a lack of performance when loading
> the UI?

Basically: no. Generally, the number of widgets (including containers)
is more important in terms of decreasing the performance than their
layout and nesting is. On sub-GHz machines you should be on the safe
side for numbers of up to about 200 widgets per dialog.

However, yet there are two methods of loading the UI supported by Glade:
1. the UI definition is stored in an XML file and being loaded and
   parsed by libglade on each start of the application.
2. the UI definition is stored hardcoded, in binary form within the
   executable.

There are a number of benefits and drawbacks of both of these ways. They
have been subject of intense discussions already, and I don't want to
repeat them here. Just this much: the libglade way is slower than the
hardcoded way at execution time. On the other hand, at compilation time,
the libglade way has no additional performance drawbacks, while
especially for very complex UIs the hardcoded way may consume several
extra minutes for every compiler run. The actual display speed is the
same on both methods, just load times may vary.

I should also note that the code output of Glade is planned to be
removed in future versions, which some people (including me) regret.