[yast-devel] Playing with YaST dialog sizes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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...) yast2-gtk looks more fancy in this aspect, and delegates more hints to the toolkit, but the height is also too big. I attach some screenshots with yast2-sudo-big (original yast2-qt) and the same ones in a modified yast2-qt ( yast-sudo-small* ) I think the ideal situation is something in the middle. For example, my modified yast2-qt basically uses the minimum space possible, which is also not the answer, however the wizard looks much nicer in small (better said, enough) size. May be some better algorithm which does not use the screen size, but basically the minimal space needed plus some buffer so it does not look really packed. Just wanted to start a discussion on this "taste". Duncan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkj91HUACgkQzR62qWZ+QtG/SQCffc6caGR7MMGNPUwLLN/10Bi1 1i4AnR3dxe1cDH35zsJddDghohcCTWNs =Yrim -----END PGP SIGNATURE-----
Duncan Mac-Vicar P. wrote:
... I think the ideal situation is something in the middle. For example, my modified yast2-qt basically uses the minimum space possible, which is also not the answer, however the wizard looks much nicer in small (better said, enough) size. May be some better algorithm which does not use the screen size, but basically the minimal space needed plus some buffer so it does not look really packed. Just wanted to start a discussion on this "taste".
What might be a problem is that the smallest size might change while you run the module, for instance, by switching from tab to tab, or from tree entry to another one. Would you like to recalculate and resize window while running a module? Because if you don't the first dialog might be just to small and the second one might not fit into the window space. On the other hand, resizing doesn't look professional and it would be nasty to resize a Wizard (Back/Next/Finish) with, e.g., four different steps where you can go back and forth. Moreover, the way Qt does it is similar to ncurses (well, ncurses you the whole screen but this is because the much you have there, the better for you). All in all, the default size is a solution for the issues mentioned above, maybe not perfect but a solution. Bye Lukas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lukas Ocilka wrote:
Duncan Mac-Vicar P. wrote:
... I think the ideal situation is something in the middle. For example, my modified yast2-qt basically uses the minimum space possible, which is also not the answer, however the wizard looks much nicer in small (better said, enough) size. May be some better algorithm which does not use the screen size, but basically the minimal space needed plus some buffer so it does not look really packed. Just wanted to start a discussion on this "taste".
What might be a problem is that the smallest size might change while you run the module, for instance, by switching from tab to tab, or from tree entry to another one.
You may not find any application in the world that has this problem, why? Yes, that is YaST specific problem, where those 2 widgets get the content replaced, instead of all the content being there, and see what you are supposed to see, then the sizes would be correctly calculated. In this case, DumbTab is not only dumb, but dumb with influece :-). Something to think on how to improve. Improving that would also solve the case we talked about dialogs loaded from xml files. Then you could actually describe all pages for the tab widget in the same file. Same goes for wizard. While it is a real issue, I wonder if yast2-gtk would resize the topmost dialog or not. Michael?
Would you like to recalculate and resize window while running a module? Because if you don't the first dialog might be just to small and the second one might not fit into the window space. On the other hand, resizing doesn't look professional and it would be nasty to resize a Wizard (Back/Next/Finish) with, e.g., four different steps where you can go back and forth.
No, there is no application in the world that will resize the main window while clicking in it. Just forget that example.
Moreover, the way Qt does it is similar to ncurses (well, ncurses you the whole screen but this is because the much you have there, the better for you).
For ncurses it is a valid case, because either you are in a terminal which can't show more than one application at the same time, or you are in a graphic console, for which it is the same case. However, assuming that in X11 mode you are the only application is not always true, and using 70% of the screen space is basically using a lot, but still not leaving space for other windows, so it is even worse as fullscreen.
All in all, the default size is a solution for the issues mentioned above, maybe not perfect but a solution.
I don't think a global design solution is just valid because it serves as a workaround for one specific issue. Duncan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkj+MTgACgkQzR62qWZ+QtFj6gCgt1gYv/C+Na/imQ83WrnX2RuH TWIAoIaARDtHhnw1ylJD45SHupikGFyu =4Vnm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Ter, 2008-10-21 às 21:44 +0200, Duncan Mac-Vicar P. escreveu:
In this case, DumbTab is not only dumb, but dumb with influece :-).
The entire Dialog & Wizard paradigm is dumb in that sense, so you will always want to have a comfortable default size in order to not annoy the user with any resizing.
While it is a real issue, I wonder if yast2-gtk would resize the topmost dialog or not. Michael?
10.3, 11.0 and svn should behave like yast2-qt. The window's size not coping with contents was an interim bug. With regard to the default size, gtk's is 600x600 pixels, while qt scales to the display resolution (to some extent). The display resolution is in pixel units though and as the needed pixels are always the same anyway, and the font will be the one influencing the needed size, setting it in font units makes more sense. However, the font is only responsible in part for the needed size, so you'd want to scale the thing conservatively. Cheers, Ricardo -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Ricardo Cruz wrote:
With regard to the default size, gtk's is 600x600 pixels, while qt scales to the display resolution (to some extent). The display resolution is in pixel units though and as the needed pixels are always the same anyway, and the font will be the one influencing the needed size, setting it in font units makes more sense. However, the font is only responsible in part for the needed size, so you'd want to scale the thing conservatively.
And the way yast2-qt scales makes sense, but except for 2 things: - it assumes for some reason that in a very small screen it is better to show part of the dialog instead of showing it very compressed. (by setting the lower limit to 800x600) - It scales infinitely up, making some dialogs look dumb on very big monitors. I think the algorithm can be improved. Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Sex, 2008-10-24 às 16:16 +0200, Duncan Mac-Vicar Prett escreveu:
Ricardo Cruz wrote:
With regard to the default size, gtk's is 600x600 pixels, while qt scales to the display resolution (to some extent). The display resolution is in pixel units though and as the needed pixels are always the same anyway, and the font will be the one influencing the needed size, setting it in font units makes more sense. However, the font is only responsible in part for the needed size, so you'd want to scale the thing conservatively.
And the way yast2-qt scales makes sense,
Screen resolution in no way determines the needed size. Something based on the desktop font would make more sense. Cheers, Ricardo
but except for 2 things:
- it assumes for some reason that in a very small screen it is better to show part of the dialog instead of showing it very compressed. (by setting the lower limit to 800x600) - It scales infinitely up, making some dialogs look dumb on very big monitors.
I think the algorithm can be improved.
Duncan
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Ricardo Cruz wrote:
Sex, 2008-10-24 às 16:16 +0200, Duncan Mac-Vicar Prett escreveu:
Ricardo Cruz wrote:
With regard to the default size, gtk's is 600x600 pixels, while qt scales to the display resolution (to some extent). The display resolution is in pixel units though and as the needed pixels are always the same anyway, and the font will be the one influencing the needed size, setting it in font units makes more sense. However, the font is only responsible in part for the needed size, so you'd want to scale the thing conservatively.
And the way yast2-qt scales makes sense,
Screen resolution in no way determines the needed size. Something based on the desktop font would make more sense.
Cheers, Ricardo
If you read the following lines, I did not say "determines", but something like "influences". Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
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
* Stefan Hundhammer
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.
How is the default size determined ? When trying to use YaST on one of the new 'subnotebooks', the initial dialog size was too high making the botton row hardly recognizable. It looked as if the dialog didn't take the display size into account. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Freitag, 24. Oktober 2008, Klaus Kaempf wrote:
How is the default size determined ?
When trying to use YaST on one of the new 'subnotebooks', the initial dialog size was too high making the botton row hardly recognizable.
It looked as if the dialog didn't take the display size into account.
There is some code that was #ifdef'ed out during the Qt4 migration because it
use a different approach for some things. Calculating the main dialog default
size was among that.
But that should really only affect "netbooks" (eeePC etc.) with very poor
resolutions - below 800x600.
CU
--
Stefan Hundhammer
Stefan Hundhammer wrote:
There is some code that was #ifdef'ed out during the Qt4 migration because it use a different approach for some things. Calculating the main dialog default size was among that.
Can you point me to that code so we can port it? Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Freitag, 24. Oktober 2008, Duncan Mac-Vicar Prett wrote:
Stefan Hundhammer wrote:
There is some code that was #ifdef'ed out during the Qt4 migration because it use a different approach for some things. Calculating the main dialog default size was among that.
Can you point me to that code so we can port it?
http://svn.opensuse.org/svn/yast/trunk/qt/src/YQUI.cc
Everything with _main_win plus calcDefaultSize(). What we had done in old
versions (that code goes a long way back) was let Qt assign any -geometry
parameters to that _main_win and retrieve the size of that window for the
UI's default size. That was never the best approach to begin with.
CU
--
Stefan Hundhammer
participants (6)
-
Duncan Mac-Vicar P. -
Duncan Mac-Vicar Prett
-
Klaus Kaempf -
Lukas Ocilka -
Ricardo Cruz -
Stefan Hundhammer