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

List:       kde-devel
Subject:    Re: Superlous configuration?
From:       "Friedrich W. H. Kossebau" <Friedrich.W.H () kossebau ! de>
Date:       2005-01-06 13:48:04
Message-ID: 200501061448.14335.Friedrich.W.H () kossebau ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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 =) 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 decent 
the danger to do worse is not that great. In opposite, by putting some 
formalism in this I see a lot of gains approaching: 
* more consistency
* less bogus handmade dialogs (those stretching to all ends, or giving half 
the screen estate to just one number)
* less code duplication
* cleaner code. 
* more styling possible
And perhaps the start for more advanced control of the options: 
* 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 
* perhaps even plugin wizards for certain option sets
By putting all this in a framework all the apps would benefit a lot! 

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

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

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

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

The trick is to deliver suitable tools to deal with this. And to deliver good 
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?

Friedrich

[Attachment #5 (application/pgp-signature)]

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


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