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. _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
