KLE

KDE Layout Engine

1. General Introduction

KLE is a automatic GUI layouting engine. It does all the layout work, and tries the most comfort possible to the developer and the user of an application.

1.1. Why a layout engine ?

As first, a short introduction into the history of GUI layouts:
     
  1. hard coded GUIs

  2. The first graphical user interfaces had all a hard coded layout. It was very difficult and time intencife to make a nice layout. You had to do everything "with hand" in your source code. If the user wanted an other font or the GUI in a bigger resolution, he could just simple forget it.
     
  3. Fixlayouting GUI designers

  4. Because hard coding every user interface was only a big pine, people started making GUI makers and designers. On each plattform exists some of kind of this designers, e.g:
      The first versions of this GUI designers where not very comfortable. But the today avaible GUI designers are this very well. You can easly add all kinds of widgets and e.g also bitmaps. You just "paint" your GUI.  They generate sourcecode or "resource" files, wich containts all information to create this GUI.

    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.
     

  5. Simple dynamic layoutengines

  6. Because fixsized GUI are not very nice, some people started thinking about technologis to make the GUI layout more dynamic. The most used technolgie for doing such a layout is, to use horionzontal/vertical layouting and gridlayouting. They where a very important step in the rigth direction. Such layoutengines are e.g.:
      There where realy a step in the right direction. It´s now possible for the user, to specify a custom font, and to resize the GUI at runtime.

    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 ... :-))
     

  7. Automaticly layout GUI engines
  8. 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 worked very long with MUI, and I was very lucky with it. But since it seems, that the Amiga is not dead, but also not realy alive, i´ve now changed to LINUX and KDE.

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.
 

2. How does it work ?

2.1 First short tutorial

With KLE you descrip your layout with horionzontal and vertical boxes.

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")));
What does this source do ?

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))
Everything from the opening parentness "(" till the closing parentness ")" now apply to this group.

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
If you not set this flag, it e.g would like this:

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))
Again, everything from the opening parentness "(" till the closing parentness ")" goes into this subgroup.

Than it adds a label and a lineedit to this group.
 
    << new KLLabel("FileName") 
    << new KLLineEdit())
Also note the secound ")"  by the KLLineEdit(). This closes the horionzontal group, and now everything goes again into the vertical group.

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())
And now, it does similar the same with the buttons.
 
<< (*(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.

2.2. How can it do this ?

To be able to do such layouting, all widgets must provide some information of there layout:  

2.3 Why do KLE use multiple intherence

To make this easy layouts possible, the layoutengine has it´s own class herarchie. Everything which has to be layouted is a KLChild. The class herarchie e.g. looks like this:

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:

NOTE: KLButton IS A QPushButton is realy TRUE
             KLButton IS A KLChild is realy TRUE

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.

For more information about this function, look at the headerfiles.

It now also provides a metaclass with information/functions like: