But all is done with a fix fontface and size. Also, if you just want to insert a button in the middle of your mask, you must move all your widgets, wich is always very much work.
On the other side, i the developer only had a 640x480 screen resultion, and the user has a 2048 x 2048 superbig resultion, it´s just a pain for the eyes of the user. He will not be very lucky with the program.
Ok, there are "workarounds" for this, e.g. if the user selects an bigger
resultion or font, the userinterface gets scaled. But most of this GUI´s
look very ugly, if they where scaled.
The bad on this technology was, that it was very difficult to make "never ugly getting GUI´s", wich also looks nice, if you make it minmized or maximized. Ugly means, that e.g. the get to short to display the text or get to just to big. It just looks very ugly if the height of the button gets bigger than it weight. Some of this toolkits provieded function to explicide set the minimum and maximumsizes of the widget. But this makes very much work.
People are very unhappy with this kinds of layoutengines. But they "must"
use it, because they want to provide the user a nice GUI. (Just send a
question to the kde-devel mailinglist -- you will get an very unique anwser,
what they think about QLayout ... :-))
This is the next step of evolution. It seems to be a simple step -- but why did only one system do this step yet ?
The layout engine just gets a little more knowhow. The know nows about the minimum and maximumsizes of the widgets themself.
The first and only plattform where such layout engines are public avaible is (at the moment) the Amiga. KDE is now getting the secound plattform with such a layoutengine: KLE
I think the first such layout engine on the Amiga was introduced by Stefan Stunz. It´s named Magic User Interface (MUI), and it looks like as it is named.
It´s also the most powerfull autlayouting GUI engine avaible (yet).
It´s general idea was, that not the developer of a programm knows, how it should look like. Only the User knows how his individual GUI has to look.
To make this possible, the programmer has only to specify a minimum of information about the look and layout of the GUI. The rest is done by the layoutengine with regards to the user settings.
It is very easy to use for the developer, and very comstomizeable by the user.
This is (at the moment) the last level of evolution
I´ve already written such an engine on the amiga, and portet it
to windows. But it´s not used there (yet).
I´ve now rewritten this engine for KDE, and named it "KDE Laoyut
Engine" (KLE).
I also want to add a new level to the history of GUI´s: The GUI should be complete costuomizeable by the user. This not only means the used fontset, background images and all such giminicks also provided by MUI. It also means, that the user could change the complete layout of the GUI, and add his own "command-execute-buttons" and images. Or just splitt the GUI from one window in some more windows, toolbars, popups or whatevery possible to display widgets.
This should be possible in a way, which allows also "not freak"
users to customize the GUI. If the user must paint the GUI, he will not
customize his GUI, because it's just to much work.
E.g. you want have this simple layout:
you must write in the source:
(*(new KLHVGroup(false))
<< setSpaceBorder << (*(new KLHVGroup(true)) << new KLLabel("FileName") << new KLLineEdit()) << (*(new KLHVGroup(true)) << new KLListBox() << new KLListBox()) << (*(new KLHVGroup(true)) << setSameSize << new KLButton("Ok") << new KLHVSpace() << new KLHVSpace() << new KLButton("Cancel"))); |
First it creates a vertical box. which goes from the top to the bottom.
Boxes are named groups in this layout engine. So all future use of group
means also box. The parameter false specifies, that this is a vertical
group. If you use true as parameter, the group will be horionzontal group,
(*(new KLHVGroup(false)) |
Now it uses the streaming operator (<<) to apply a manipulator.
In this case, it is the setSpaceBorder-manipulator. It sets the "SpaceBorder"
flag of the vertical group to true. Than the group leaves a 4 pixel
width border free on all of his sides.
<< setSpaceBorder |
Now it creates a horionzontal group, wich goes from the left to the
rigth and adds the new group to the parent vertical group using the
streaming operator.
<< (*(new KLHVGroup(true)) |
Than it adds a label and a lineedit to this group.
<< new KLLabel("FileName")
<< new KLLineEdit()) |
The same thing is done with the two listboxes. First there is created
a horionzontal groupbox, and then the two listboxes are inserted.
<< (*(new KLHVGroup(true))
<< new KLListBox() << new KLListBox()) |
<< (*(new KLHVGroup(true))
<< setSameSize << new KLButton("Ok") << new KLHVSpace() << new KLHVSpace() << new KLButton("Cancel"))); |
But there are two differnts. First it uses the streaming manipulator "setSameSize" to set the SameSize flag on this group. Than there are two space objects added to this group.
Spaces are just empty areas wich are usefull to fill up your layout, or to aligend something.
SameSize means, that every widget in this group gets the same space.
If you not set SameSize, the layout would look like this:
As you can see, the "Ok" button has a smaller size than the "Cancel"
button.
You can have a look to this layout, if you start the programm tour1 from the example directory. Just play around with it and resize it. Just taste the feeling of resizeable "not ugly getting" GUIs.
KLChild
|- KLGroup
| |- KLHVGroup
| |- KLGridGroup
| \- KLPageGroup
|- KLWidgetBase
| |- KLButton
| |- KLLabel
| \- KLLineEdit
\- KLHVSpace
Because of this, it is very easy to add new types of groups, or other layout displaying widgets. (E.g. GroupBoxes, TabCtrls, ...)
Classes like KLLabel or KLButton (wich are QtWidget) must multiple intherence, because there needs to be a:
There is NO multiple intherence of the same baseclass.
It does NOT make sence to NOT use multiple intherence. It just would more work and everyting more complicated and painfull. This is not in the sence of this layoutengine ! It would bring NOTHING than MORE WORK !
KLChild has some abstract virtual functions, which controls the layout and the display.
It now also provides a metaclass with information/functions like: