Idea: KAction based dialogs

[Dirk Schönberger]

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

> you can define methods (inc slots) in Designer and then implement them in
the
> ui.h file (in Designer) and you're taken care of. regardless, any XML
driven
> format will have the issue that at some point the rubber hits the road and
> you need to write code.

Agreed. But I somehow more like to being able to implement my behaviour by
working with abstract "actions"
instead of having manually to work around with signals, slots, properties
and the like.
I think the KAction concept is a really nice abstraction beyond the "low
level" GUI toolkit.
You are able to centrally implement the needed toolkit (create menus,
toolbars, dialogs, accelerators and the like) calls by providing
proper constructors for the re-used actions and implementing proper plug() /
unplug() for any custom actions.

Seems I am more the type who likes patching around some nice declarative XML
grammar than stupidly pushing around the mouse to hunt around missing
accelerators in a complex GUI design...


> the question is whether it's best done through a KAction style
methodology, or
> a more traditional "writing code" approach. i just don't see how KActions
(or
> something similar) would interact with the UI on a level that would make
> introducing something brand new worthwhile.

See above.
After having coded an normal menubar with Ruby in Fox toolkit, I don't want
to miss actions and XML GUI descriptions any longer.
And I don't really like RAD GUI designers, because it is too easy to miss
simple things like accelerators or layouts.
This is more easily done with the traditional search/replace in a text
editor.
I don't really want to change a XML file produced by Qt designer. Too simple
grammar, and don't really reflect things I want to achieve.

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

> you mean like the pages in a KJanusWidget? yes... as i stated in my
previous
> email this is because we don't have the templates in Designer for this.
but
> this is really not a big issue. instead of having one mamoth UI file, you
> have one per page. this actually works out nicely in the end as these
> multi-page dialogs often end up getting chopped up and/or reorganized over
> time.

Yes, but I would like to be able to shuffle around the GU at runtime,
without having to re-compile the whole application.
Think power users, think distributions which may want to change the layout
of a GUI to make it more their target audience.
Things like being able to run the same application without recompiling on a
2048xX monitor, a 800x600 screen and a PDA / smartphone.
If you model your pages as separate classes, this would be not possible,
because in order to support smaller screens, perhaps you may
create more pages with less content on a page.

> > - You have to explicitly create layouts using the KDE widget and window
> > classes

> this is a feature. beyond very simple dialogs, layouts should be designed
not
> generated.

The Qt layout model has a finite set of methods (the add* elements in
QLayout and children) and properties.
I think the whole set could be modeled with my proposed concept. So you have
the whole power of the Qt widget model disposable at your XML editing
hands.
If I can avoid it, I don't want to introduce features which would be not
possible with normal calls to the Qt or KDE API.

> > - You have to hope that another user has KDE widget plugin installed

> no hoping required, this is part of kdelibs. exotic widgets are more
> problematic as you have to distribute your plugin, but i've done custom
> widgets in KDE using Designer (ksnapshot) and it does just fine.

Everything is fine if you limit the editability to compile time and
generated code.
My whole idea is to extend editability to runtime and declarative approach.


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

> true. the only reason i can see for wanting this is to write an app that
has
> both a Qt-only as well as a KDE interface. there are other ways of
achieving
> this, and there are other problems besides the GUI that stand in the way
as
> well.

I would be more interested in e.g. calendar actions.
Define a DateInputAction. Dependent upon the context you may want to have a
input line widget with a validator, or
a full-blown calendar widget.
I more like the calendar widgets. Other people may more like the input line
solution, because of better keyboard navigation, or whatever.
I am more a mouse type, I suppose.
Why am I forced to a mixed set of both, according to the whim of the
respective developer of the application...

> > - simple dialog creation at runtime from XML resource files, which are
> > modifiable by a user

> already possible with Designer, and quite honestly not a desireable thing.
at
> least not if you are a help desk tech or care about usability.

I understand your concerns, but I think I have to disagree.
I think you could enhance useability if you proide the possibility to change
the GUI layout at runtime.
You may either change simple things like the spacing, or more complex things
like the switch from multi-tab dialog to the icone list of the left style of
dialog.

Basically I think the user documentation should include a list of defined
actions for a given dialog class, where the actual dialog is just a default
layout.
I would really like to be able to play around with dialogs like the find
dialog or the file open/save dialog in KDE, and create custom layouts for
collecting ideas.
Things like the discussions about the Gtk file dialog in the near past, but
without code changes and at runtime.

> run time would just be insane, however; besides being slower the
opportunity for massive failure is quite high.

I agree my solution is slower, but I think with a few changes to the XMLGUI
framework the performance could be enhanced.
Any my grammar is quite simpler less complex hierarchies, more attributes,
more tags - greater expressivity) than e.g Qt designer grammar.

> "Oh. You mean i can't change m_technicalname to WhatIPrefer?"

I don't want to change member variables in the source code of the dialog.
But I want to be able to push e.g. the "dir_list" action from a nested VBox
/ HBox to a grid layout

Eg. default layout


<Dialog name="decrease_colors">
    <GroupBox caption="colors">
        <VBox>
            <HBox>
              <Action name="depth_8bit"/>
              <Action name="depth_4bit"/>
              <Action name="depth_1bit"/>
            </HBox>
            <Action name="depth_custom"/>
            <Action name="num_colors"/>
            <Action name="use_fs_dither"/>
        </VBox>
    </ButtonGroup>
</Dialog>


more useable layout

<Dialog name="decrease_colors">
    <GroupBox caption="colors">
        <Grid columns="3">
            <Action name="depth_8bit" constraints="x:1;y:1"/>
            <Action name="depth_4bit" constraints="x:1;y:2"/>
            <Action name="depth_1bit" constraints="x:1;y:3"/>
            <text constraints="x:2;y:3">(Black / White)</text>

            <Action name="depth_custom" constraints="x:1;y:4"/>
            <Action name="num_colors" constraints="x:2;y:4"/>
            <text constraints="x:3;y:4">(2 - 256 Colors)</text>

            <Action name="use_fs_dither" constraints="x:1;y:5;w:2;h:1"/>
        </Grid>
    </ButtonGroup>
</Dialog>

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

> ok. let's take a concrete example. say... hrm... *looks around* ksnapshot.
> what actions would map to the buttons, exactly? and how would using a
KAction
> be ANY easier than using point-n-click to define which slot that button
> calls? i usually do all of this in Designer, BTW.

Unfortunately I don't have Qt designer open, so I have to take a quick shot.
Perhaps I would start with the following XMLGUI resource and add layout
constraints as needed?

<Dialog name="ksnapshot">
  <Grid>
   <Action name="snapshot_preview" />
   <Action name="snapshot_new" />
   <Action name="snapshot_save" />
   <Spacer type="vertical"/>
   <Action name="snapshot_print" />
   <HLine />
   <Action name="snapshot_delay" />
   <Spacer type="horizontal"/>
   <Action name="snapshot_include_decorations" />
   <Action name="snapshot_area" />
   <Spacer type="vertical"/>
  </Grid>

</Dialog>


In my source code I create a Action instance for each action in the
resource, with proper types.
Initialization of theses actions would be in the C++ source.

KAction *snapshotPreview = new DlgWidgetAction ("snapshot_preview", ...);
previewAction->setWidget(...)

KAction *snapshotNew = new DlgButtonAction("snapshot_new", ...);
KAction *snapshotSave = new DlgButtonAction("snapshot_save", ...);
KAction *snapshotPrint = new DlgButtonAction("snapshot_print", ...);
KAction *snapshotDelay = new DlgNumInputAction("snapshot_delay", ...);
KAction *snapshotIncludeDecorations = new
DlgToggleAction("snapshot_include_decorations", ...);
KAction *snapshotArea = new DlgSelectionAction("snapshot_area", ...);

Probably there are needed more action classes than in my current prototype.

> >   constraint "qt | kde", so that the switch between Qt and KDE dialogs
> > would be
> >   possible for each user independently.

> and this is a feature ....... how? and what about the rest of the app?
would
> it continue to use KDE libs underneath? if not, then when they switch to
KDE
> mode, what about the widgets that need kapp or other KDE infrastructure?

Currently the toolkit switch is just a theory / idea which I haven't
explored further. I don't think there is a real
comparison between QDialog and KDialogBase, but perhaps between QComboBox
and KComboBox?

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

> designer supports grid layouts, and you don't even have to sit down and
figure
> out the cells yourself.

When I last checked Qt designer (quite shortly I admit), I was not really
able to create dialogs which resize properly.
Somehow my dialog widgets stayed in the left upper corner of my dialog.
Perhaps I am more accustomed to HTML style tables where I can specify
multi-rows and multi columns explicitly in a text view / editor.

> QWidgetFactory.

> it's a bit funny that since you don't know how to do it in Qt, you would
> rather design a whole other XML-driven infrastructure. learn the tools we
> have, it's a lot less effort =)

The ability to merge part documents to a result XML document was the thing
which impressed me the most after I started my
hobby application. I am a rather newbie in Qt application programming. Until
now I was more into the theory and into "middle ware" programming
(e.g. my KPainter project in kdebonbeta, which is sadly rather neglected in
the last time)
After I tried to drag together a simple dialog like my "decrease color"
dialog, I decided that I don't really like the drag-and-drop style of GUI
design)
I have some experience in Java / Swing / JBuilder style GUI design, where I
experienced the same problems.
And linear C++ stlye Qt design programming I find tiresome, too.
A GUI is inherently hierarchical, which cannot simply be expressed by C++
style call sequences.

> > really feel like implementing a full framework like for KCMs.

> you don't have to. you could go with the KDE plugin stuff (mmm..
templates) or
> you can just load the XML at run time. designer supports making
signal-slot
> connections!

I intend to use the KDE plugin stuff, in reality I want to use my hobby
application in order to learn the "document based" features of the Qt
framework -
document, controller, view tools, actions; plugins, scripting and the like.
But I think this may take a while.

I just don't know how I am about to merge two Qt designer  XML files, i.e.
something lie the following


<Dialog name="image_effect">
    <VBox>
      <HBox>
        <Action name="image_before"/>
        <Action name="image_after"/>
      </HBox>
      <HLine/>
      ¶ms;
      <HLine/>
        <Action name="effect_apply"/>
</Dialog>

<Panel name="decrease_colors" merge="params">
    <GroupBox caption="colors">
        <Grid columns="3">
            <Action name="depth_8bit" constraints="x:1;y:1"/>
            <Action name="depth_4bit" constraints="x:1;y:2"/>
            <Action name="depth_1bit" constraints="x:1;y:3"/>
            <text constraints="x:2;y:3">(Black / White)</text>

            <Action name="depth_custom" constraints="x:1;y:4"/>
            <Action name="num_colors" constraints="x:2;y:4"/>
            <text constraints="x:3;y:4">(2 - 256 Colors)</text>

            <Action name="use_fs_dither" constraints="x:1;y:5;w:2;h:1"/>
        </Grid>
    </ButtonGroup>
</Dialog>


> perhaps look at glueing XMLUI to Designer UI files?

I thought about it too, but I don't think that the action concept mix well
with the widget hierarchy and code generation approach of Qt designer.
There is no easy way to express KActions in Qt designer, and QActions are
limited to toolbars and menubars (basically just buttons / menu entries)
I hae found no way to define custom actions based on QActions, like a
NumInputAction or a SelectionAction.

> p.s. no need to CC me  on replies =)

I am not subscribed to kde-core-devel, so I think I am on moderation, which
made the delivery rather asynchronous in the last days.
By CC'ing you I INtended to get a more "synchronous" reply.
I will try if it works without a CC

Regards
Dirk