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

List:       kde-devel
Subject:    Re: Superlous configuration?
From:       dirk.schoenberger () sz-online ! de
Date:       2005-01-06 10:45:53
Message-ID: 58889.217.232.87.239.1105008353.squirrel () mail ! sz-online ! de
[Download RAW message or body]

> well, i think we'd need something a bit more flexible (and certainly
> better
> documented =) than XMLGUI to start with. would be interesting to see how
> pervasive such a thing could become, though the problem it's addressing
> would
> have to be phrased first.

While I may agree with the "better documented" part, I am not quite sure
about the "more flexible" part. At least from my tests with it it seems
that XMLGUI is rather flexible, i.e. it can do anything I want from it.
Basically you would have to define your own schema and interpretation of
this, which should hopefully express all features of the Qt component
model. After that you can describe your dialogs via XMLGUI.
The C++ code should contain only the action declarations, their
initialization (i.e. which properties are set with which values), and the
behaviour of your dialog in terms of changes to actions (changing a value
in action a disables action b, such stuff).

You would have to create a new class hierarchy of KAction based classes,
which implement the actual building (i.e. a KIntInputAction creates a
KIntNumInput widget). The last part could be made stylable, so that the
action can decide which component to create at runtime.


>
> i really don't know how you'd do things like config dialogs in this
> fashion
> and have them still look decent.
>

I have sample code which tries to implement a large subset of the Qt
component / widget model, complete with component, layouts and layout
constraints. There seem to be some problems left, but my dialogs look at
least similar to their "manually" created cousins.
This was the result of some two week "proof of concept" type  project. I
assume it coould be done better with proper requests, test cases and
stuff.

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]