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

List:       kde-devel
Subject:    Re: Idea: KAction based dialogs
From:       Ravikiran Rajagopal <ravi () ee ! eng ! ohio-state ! edu>
Date:       2004-02-12 15:53:55
Message-ID: 200402121053.57268.ravi () ee ! eng ! ohio-state ! edu
[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.

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

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

The content, which is typically a list of actions and action groups, would be 
represented as an XMLGUI rc file. 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.

With the addition of one class to kdelibs, we would then have this available 
to all applications. 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.

Regards,
Ravi

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