Idea: KAction based dialogs

[Aaron Seigo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On February 13, 2004 9:39, dirk.schoenberger at sz-online.de wrote:
> 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.

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.

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

as for multiple-tab dialogs, it happens all the time.

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

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

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

> - 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. the way we 
currently use Designer allows compile time changes to be very easily made; 
people have access to the source code and so there are no barriers to 
tweaking. run time would just be insane, however; besides being slower the 
opportunity for massive failure is quite high.

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

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

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

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

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

if you use QWidgetFactory, you're covered. more sane is to simply have 
multiple versions of the software. having dynamically switchable UIs on apps 
is insane for usability: "So... are you using version Alpha, Beta or Gamma of 
the config dialog?"

> 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

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

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

btw, KConfigXT dynamically binds into GUIs at run time, including those 
generated with designer. so it is possible and it does work. i'd love to see 
more such capabilities emerge, but i don't think the road is paved with more 
XML schemas. we have enough of those already.

perhaps look at glueing XMLUI to Designer UI files?

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

- -- 
Aaron J. Seigo
while (!horse()); cart();
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQFALQp61rcusafx20MRAqZIAJwOjzsMNrLJHKZ6wbI5HmeJFXxNlQCfXvs+
xxQyFg6iCR/Il0qzMPS28x4=
=pLb9
-----END PGP SIGNATURE-----