Idea: KAction based dialogs

[dirk.schoenberger at sz-online.de]

> > - you could use the KDE framework (use e.g. subclass from KDialogBase)
and
> > implement your dialog GUI manually
> > - you could use the Qt UI designer, where you can design your UI
> > graphically, in order to use it, you create source code from it.
> > Theoretically it should be possible to load the UI at runtime, but
this is
> > not quite easily to accomplish.

> QWidgetFactory makes it about as easy as possible. what are you missing
from
> that?

Basically I don't see no easy way to add "behaviour" to the layouts built
by Qt designer. Basically you have to inherit from them and add your own
method implementations.
This is not easier if you use QWidgetFactory.

Additionally, at least in the examples I have seen in KDE CVS, you rarely
design full multi page dialogs in Qt designer. Instead you design single
pages, which are assembled at runtime.
If you use this approach, fully dynamically loading of dialog layouts at
runtime is not possible.

> > Furtheron, if you use Qt designer, there
> > are some problems because you don't easily get dialogs which feel
"native"
> > to KDE (use KDE components, and the like)

> *raises one eyebrow*

> i do this all the time. what _IS_ missing are Designer templates for
> KDialogBase and KMainWindow to complement the QDialog and QMainWindow
> templates. but this is generally quite trivial to work around by making
your
> Designer layout a QWidget and then instantiate it as a the main widget of
> your dialog/window.

- You have to explicitly create layouts using the KDE widget and window
classes
- You have to hope that another user has KDE widget plugin installed
- It is not really easy to switch between Qt and KDE mode. Qt designer
basically
  are an object model dump, with explicit names for classes and properties /
  fields. There is no abstraction, so that a "button" tag could be
implemented by a
  KButton, a QButton or a Gtk button

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

> i don't see the benefit of having yet another XML syntax for accomplishing
> exactly what Qt's .ui files provide, minus the GUI designer and all the
> testing and n^m features =)

- simple dialog creation at runtime from XML resource files, which are
modifiable
  by a user
- a defined way to add behaviour to a dialog. Behaviour is implemented by the
  KDE action framework, in the XML GUI description are only action references
- easy switch between Qt and KDE versions of a dialog. If a KDE component is
  developed with additional functionality to a Qt component, it simple is
refernced
  in the action's plug method, so that all dialogs which use this actions
  automatically use the new component. Theoretically you could add a dialog
  constraint "qt | kde", so that the switch between Qt and KDE dialogs
would be
  possible for each user independently.

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

> XMLGUI is a bit orthogonal to UI layouts. i've considered in the past
how the
> two could be usefully combined, but i've only be able to come up with some
> pretty contrived examples. of course, i could be missing something and
would
> be happy to consider possible synergies between the two concepts.

Not really. Simple dialogs which would use only QLayout::add (QWidget*)
are straight forward (see my first sample dialog description). In order to
be able to use  the more complex add* methods, like
QGridLayout::addMultiCellWidget,
I introduced layout constraints, which have indeed a not obvious syntax
(see sample description 2)
The second possibility gives you much better control about dialog layout
than the first possibility.

> all the other items you suggest (versions, merging) is already possible,
> though not automagically (with exceptions for things like KCMs). which is
> actually good because at the dialog level you rarely want such things.

I am not quite sure how you would implement multiple versions of a dialog
which is generated from a Qt designer file. Multiple ui files equals
multiple classes, which would have to be selected somehow.

For merging, my use case would be dialogs for a image editor. In a base
class, you define a dialog skeleton, which e.g. contains widgets for an
image preview.
In subclasses you add the controls to specify the parameters of a image
effect, which can be previewed in the preview widgets.
Not quite sure about how to solve this with Qt designer, and I don't
really feel like implementing a full framework like for KCMs.

Regards
Dirk