[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Idea: KAction based dialogs
From:       dirk.schoenberger () sz-online ! de
Date:       2004-02-12 16:31:39
Message-ID: 58419.212.185.245.37.1076603499.squirrel () mail ! sz-online ! de
[Download RAW message or body]

>
>> So I would like to propose another way to implement dialogs classes.
>> Implement your GUI as a set of actions, which interact with each other,
>> like in the recommended implementation for forms (main windows). Define
>> the actual GUI layout in an external resource file, which is load and
>> evaluated at runtime. If you use the XMLGUI framework for it, you can
>> get
>> the other features of this framework, too, like multiple versions of the
>> dialog, possible merging of sub documents, etc.
>
> Like KConfigXT and friends, this is yet another push towards autogenerated
> code. However, I do not see why runtime parsing of the widget
> configuration
> is necessary, unless you wish the layout to be modifiable.

Not really. My idea doesn't revolve around autogeneration, but more around
creating proper "controller classes" (the action classes like
DlgRadioBtnAction, DlgToggleBtnAction and the like) which generate their
associated UI at runtime.
And yes, I would make the layout of dialogs modifiable at runtime.
Things like "advanced" / "beginner" versions of the same dialog, things
like useability concerns (create more groups for better separation, add
some spacing between the dialog elements), which don't impact the actual
"behaviour" of the
dialog.
You still implement the actual behaviour in compiled code with C++ or the
language binding of your choice.

>
>>     <GroupBox caption="colors">
>>         <Grid columns="3">
>
> This is mixing up the visual representation with contents. I would rather
> see
> this split up into two files:

You already split it up - the XMLGUI representation and your C++ code.
The XML is just for wiring the actions together.

>
> 1. The visual representation
> 2. The content
>
> The visual representation would be a simple Qt designer file. Since we
> wish to
> have autogenerated code, the handler of any kind of visual representation
> must be aware of the allowable classes/widgets. Note that this is exactly
> the
> capability of Qt designer with KDE widgets. The issue of run-time vs
> compile-time parsing is also handled by designer (via libqui).

I would agree if Qt designer files would be really human readable /
modifiable.
But instead they are just a fancy memory dump ;)
You don't really want to load these files at runtime, much less change them.

>
> The content, which is typically a list of actions and action groups, would
> be
> represented as an XMLGUI rc file.

In the current XMLGUI design the actions are only referenced by name. The
actual action implementations are done in real source code.

> We would simply connect the actions with
> the appropriate widgets at run-time via the XMLGUI framework as we do now.
> The missing glue functionality is what needs to be provided.

> I would follow the design of KAutoConfigDialog/KConfigXT and friends and
simply
> map between the widget name and the action it represents.

>From what I understood about KConfigXT, it tries to autogenerate the
actual GUI.
This is not what I want to accomplish.
I would like to have the GUI created dynamically, but modifiable at "runtime"

>
> With the addition of one class to kdelibs, we would then have this
> available to all applications.

I agree, but I think there would be binary compatibility concerns, which
would delay inclusion of my class into kdelibs.
That's why I proposed to test the framework in one or more applications
first.

> Note that much of the design work for a glue class can
> be copied from the configuration classes mentioned above.
> Automating general dialog creation is a logical successor to automating
> configuration dialog creation, and I would be surprised if you were the
only
> one considering this idea.

Again, my proposal is not about autogenerating dialogs, but instead about
being able to better specify the visual appearance of dialogs.

If my work would be just an extension to KConfigXT, I think it would be
redundant and pointless.

Regards
Dirk

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]