--===============1071258669==
Content-Type: multipart/signed;
  boundary="nextPart1353003.9DzIxkWsdr";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1353003.9DzIxkWsdr
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Donnerstag, 6. Januar 2005 11:45, schrieb dirk.schoenberger@sz-online.de:
> > well, i think we'd need something a bit more flexible (and certainly
> > better
> > documented =3D) 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.

Sounds so cool!

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

As IMHO the majority of today's config dialogs do everything but look decen=
t=20
the danger to do worse is not that great. In opposite, by putting some=20
formalism in this I see a lot of gains approaching:=20
* more consistency
* less bogus handmade dialogs (those stretching to all ends, or giving half=
=20
the screen estate to just one number)
* less code duplication
* cleaner code.=20
* more styling possible
And perhaps the start for more advanced control of the options:=20
* marking of options which have been changed
* applying changes temporary or persistent, to the local view or all views
* import and export of sets of options (you get themes for free)
* creating different profiles=20
* perhaps even plugin wizards for certain option sets
By putting all this in a framework all the apps would benefit a lot!=20

Just have a look at the "Look'n'Feel" dialogs and analyse them: They all do=
=20
the same (from an abstract POV). But each has a different handling, layout=
=20
and so. If all would be generated by such a framework you would not have to=
=20
relearn for every single dialog.

Disclaimer: I have not used KConfigXT yet, but you have the Config GUI=20
automatically derived, right? So:
I have not made some great research but from my experience most dialog entr=
ies=20
can be directly mapped to some stored config value (thus KConfigXT). I woul=
d=20
bet that with some effort  KConfigEditor could be merged with KConfigXT.=20
Those more advanced options could be moved into lower option folders which=
=20
would not be shown by default within the tree view.=20

I agree with Aaron and surely a lot others that everybody including power=20
users is at least sometimes lost in the big tree of KDE options so the tree=
=20
approach might no longer work. But instead of adapting the object (number o=
f=20
options) to the tool (tree) I join those who propose to use different tools=
,=20
like search (and bookmarks, history, all the things you know from the www=20
where the same problem arose).

While KDE gets bigger the number of options will grow. And cutting them is =
not=20
the way to go. Most of them serve some purposes that help to adapt to local=
=20
needs or personal whishes.
So this is about cultural freedom: Most of us do not want to be forced to e=
at  =20
with fork and knives instead of by hand or vice versa, only because someone=
=20
thinks this or that way is better to achieve a goal. This is a option we=20
would like to have. Isn't this one of the reasons why we are writing free=20
software?

The trick is to deliver suitable tools to deal with this. And to deliver go=
od=20
defaults. Themes come into play (see above) :)

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

Would you like to offer your sample code for us to play with?

=46riedrich

--nextPart1353003.9DzIxkWsdr
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBB3UGeECqmVFXwdrMRAkEIAKCINLnOqsFWJW18fNTkXdzj1OvbLQCglVxl
NrPepH/O9jW5yb51LB+Ubug=
=mzOv
-----END PGP SIGNATURE-----

--nextPart1353003.9DzIxkWsdr--

--===============1071258669==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

--===============1071258669==--