On Dienstag, 21. Oktober 2008, Duncan Mac-Vicar P. wrote:
Something I don't like from YaST-qt is the default size of dialogs (matter of taste). yast2-gtk handles it a bit better, but still not perfect.
After the bug where yast2-qt did not fit on subnotebooks I got inspired to do some experiments with yast-qt size.
It seems yast2-qt uses sizeHint for all widgets, except for the topmost, which is calculated artificially using the screen size, which results in lot of blank space and I have to turn my sight 10 meters down from the only line of text to the point I see the buttons (yes, I like to exaggerate...)
You are aware of the difference of UI::OpenDialog() vs. UI::OpenDialog(`opt(`defaultsize))? `opt(`defaultsize) specifies that a predefined default size (800x600 in most cases) should be used rather than the preferred sizes of the child widgets. http://forgeftp.novell.com///yast/doc/SL10.3/tdg/YUI_builtins_OpenDialog_wit... http://forgeftp.novell.com///yast/doc/SL11.0/tdg/bk08ch01.html#layout-howto
yast2-gtk looks more fancy in this aspect, and delegates more hints to the toolkit, but the height is also too big.
If yast2-gtk simply overrides `opt(`defaultsize) then that is a bug. This is
how that option is specified.
Applications can choose what they want their windows to look like. Just using
the preferred sizes of the widgets in that dialog is fine; however, that
means that in many cases sizes will have to be explicitly specified by the
application (MinSize(), MinWidth(), MinHeight()). For example, all widgets
that can scroll don't have a really useful natural preferred size; for those,
you need external constraints. You can wrap them individually into MinSize()
etc., or you can put a MinSize() around a parent VBox() or HBox() that holds
several of them.
But if an application clearly specifies `opt(`defaultsize), then it should
clearly get some default size. This does not necessarily mean that we have to
stick to 800x600 for all eternity. But the specification makes a promise, and
we can't just throw that promise overboard in the blink of an eye. A lot of
code would very likely break.
CU
--
Stefan Hundhammer