I was browsing gtk.org in the hope to find a guide about how application developers are supposed to manage the contents of the windows they are about to draw in their applications. Unfortunately I found no guidance about that.
Lets take the window where I type this email right now for example. Most GUI have that “New Mail” window, with a menu bar at the top, followed by the list of author and recipients, followed by subject and finally the text area. At the end there is maybe a status row.
How is an application supposed to know what the maximum “height” and “width” of that window is? In my case the total screen height has to be subtracted by the application panel of the desktop, but maybe that panel is vertically aligned so more of the full height would be available. Then this window may have titlebar, and some border of varying width does exist as well.
If all of the above would be known by the application, it could start collecting the various items to be drawn inside that window, and make decisions about how the available space should be distributed. For example, an email with many recipients will result in a long list and therefore take too much space. As a result, the text area below it may be just one line or not be shown at all. So it has to decide if that list needs a scrollbar or not.
Similar with the width of that window. The app may decide that the width should be old-style fixed-width 80 chars. This would leave little room for the menubar and the recipients, which may have very long names.
Unfortunately, the app I decided to use goes the easy way: it asks for the size if the window and stores that size in its preferences in the hope the values will fit just fine for the next email. As you can guess, these values will not fit the next time. It also uses gtk_widget_set_size_request and similar with often hardcoded values, which means various buttons may overlap or whatever damage can be done with that approach.
I browsed the API documentation, and maybe one can find out by try-and-error. It also looks as if gtk3 has more knobs than gtk2 had, based on the available function names. It would be good if a document exists to obtain and use the information I have outlined above.
I think you’re overthinking this a bit… IIRC without a default size, a window will be sized so that it can fit its content. If you want a default window size (e.g. because the auto size is too smushed), you’d just pick one that seems to comfortably visually fit what you want. It’s still a default, so if the window needs to be bigger it will be.
A lot of times when you might try to resize e.g. a button to make it bigger, you’d be better off adding some margins to it instead.
That being said, you can measure the size of a widget, but in this case I don’t think it would help too much.
I wish you the best luck; this sounds like a nightmare to work with
Maybe I did not ask the question properly. I’m not an app developer, nor do I know much about gtk. So the terms used by my might be wrong.
IMO an application should have a way to easily query how large a window can be, likely the state when it is “maximised”. Within these bounds it has to decide how to size the individual widgets. For example, how many entries in a “recipent list” should be shown per default to still allow enough room for the “text entry area”.
So the application has to measure the size of the involved widgets, and it has to measure the maximum available room to draw them. Then it can decide which of the involved widgets need some adjustment in size.
As another example, take any settings dialog of a random application you may have installed. Typically the size of such window is either to small, one has to resize the thing despite that fact that it is shown on a 24" display. Or it is much too large for the content that is supposed to be shown, just because the author of the application settled on some unusal large constants. It would be better if the application would briefly calculate the size of each “settings tab” to set the initial size of the window large enough that, in the current configuration, no unneccesary resizing or mouse movement is required.
It sounds like you’re focused a bit too much on setting the size request of a window. That is not really how modern application development works for Gtk applications. Instead, there is the concept of a natural size (all widgets in their natural state, as the designer intends) and a minimum size (the minimum required size to be useful to the user).
Widgets can provide a virtual function to help determine those sizes. For example, there is get_preferred_height() and get_preferred_width(). These can provide both of those sizing details. Also, there are height-for-width, or width-for-height variants when the sizing is dependent on the size of the other axis.
When displaying a window, the size-request machinery determines the natural size, the minimum size, and the sizing of the monitor to come up with something optimal. Further more, if geometry hints are set, it may need to enforce things a bit more (as a terminal might do to force sizing to dimensions of a glyph).
I’m not an app developer, nor do I know much about gtk.
I guess being an actual developer and knowing some basics of GTK or other GUI toolkits is a better starting point for a discussion
GTK does most layout automatically, and often it is not that bad. For example, if your main window has some containers with widgets like labels and buttons, and you do not specify any sizes, then the actual window size adapts to the text of the labels and buttons. That is convenient for the developer and generally what the users prefer. Larger fonts, longer text: ==> larger main window. Since some years that works for example also for text entry widgets, you can specify how many text characters should be visible. For other widgets like text fields or treeviews it may work not that well, but here the problem is the often unknown content. It can be really hard, imagine user opens a text file with only five short lines text. It may be fine to make the text area that small, but maybe the user wants to write much more text?
You may compare that with other GUI toolkits, I think FLTK or wxWidgets: There you have to size and position all yourself. Which can be really difficult, much work and results may not be that nice.
I think you are complaining because some of your tools may behave very unfriendly with very bad default sizes. That can occur because the developer was not very smart, or because of bugs of the toolkit.
Layout engines for GUI layout is a very broad field. It has become much more complex since apps should support gigantic screens up to tiny mobile devices. So I can understand your complains. My advice is to try to create an app and then ask here when layout is not perfect.
Yes, I already thought about that and will prepare a standalone test case. Maybe during extraction of the relevant code from the app I may spot the flaw in their logic.
