GUI framework in kde4

[Friedrich W. H. Kossebau]

Am Sonntag, 2. Juli 2006 21:08, schrieb Hamish Rodda:
> Hi,
>
> Please see the following document created at Trysil about improving XMLGUI
> (actually, mostly replacing it, but preserving + improving features):
>
> http://wiki.kde.org/tiki-index.php?page=KDE+4+GUI+framework
>
> Feedback encouraged :)

Food for thought:
In many programs one can see the same sets of actions, e.g. for zooming, 
clipboard interaction, formatting, navigating, etc.
Each set operates on a certain aspect: like zoom of view, or the document/data 
model, or style of current text, or view location, ... This is emphasized by 
the grouping of the corresponding gui items.
The patterns are usually repeating in every program. Still in every program 
the wiring of all those actions and their gui representation has to be and is 
done manually.

What about giving this better support by the framework? I tried to make up 
some concept paper, codename Toolets, along with some example implementation, 
yet could not finish it. Perhaps you are smarter than me and can make more 
out of this faster :)

So here some idea for it: 
In system modelling you have the terms Boundary, Control, Entity. The terms 
should be selfexplaining :) In KDE programs Control and Entity are usually 
left to do for the programmer, while the boundary is supported by things like 
XMLGUI. Now, what about supporting the controls recognized as usual, too? The 
controls would operate on the document/view* by standardized interfaces for 
common aspects (see above).
So if somebody is developing a new datatype modell and a suited view, e.g. for 
wantondocs, if she is fine with using existing document 
interfaces, "setGUI()" would be nothing more than "Tools.setCurrentModel( 
model ); Tools.setCurrentView( view );" or something.
Perhaps this approach might even get one better support for accessibility, but 
then I do know nothing about that.
Surely it delivers/forces more consistency (remember the mess with the order 
of zoom buttons?). And easens the developing, reduces code bloat for the 
single developer, structures programs even more.

* From a certain point of view a "view" is a document, too, a structured set 
of data, e.g. zoom, size, sector of doc, view angle, draw settings.

So far an idea, you are free to ignore it :)

Regards
Friedrich