KAutoConfigDialog & Usibility

[Matthias Kretz]

Hi Ben,

you already heard from me about this :-) but I say it again so that everybody 
knows what I think about it.

I think KAutoConfigDialog should provide only one page. As soon as you want to 
do a dialog with more pages use KConfigureDialog (even better: use it for 
every cfg dlg). It will automatically choose an IconList or a TreeList 
depending on the pages it has to combine (you can specify the hierarchy in 
the .desktop files of the pages). For example you need to have a TreeList in 
Kontact while a simple app with 2 pages in the dialog looks stupid if it 
isn't using an IconList.

When I say "page" I always think about a call to KDialogBase::addPage(). It 
would be nice if KAutoConfigDialog (which I would rather call KAutoConfigPage 
then) would provide KCMs (probably by making KAutoConfigPage inheriting from 
KCModule). These can then easily be used in the KConfigureDialog.

PS: Don't complain about the extra work ;-) I told you before you started 
KAutoConfigDialog that I'm working on a cfg dlg and that we should coordinate 
our work...

On Tuesday August 26 2003 05:29, Benjamin Meyer wrote:
> From getting on the dot an interesting item arose for KAutoConfigDialog:
>
> Should I limit developers to requesting either a) single paged dialog or b)
> multi paged dialog and then if multi use the global config to determine
> what type (icon list, tabbed, tree)?
>
> Currently it simply has a function default value of IconList.  Moving to
> the above would a) break binary compatibility b) source compatibility in a
> few cases (which I could quickly go through cvs fixing).  But it has the
> really good benefit of making all of the configure dialogs (that use
> KAutoConfigDialog) to look the same while at the same time still allowing
> the user/admin to select a global look that they like.  Thus giving a
> better user experience.
>
> -Benjamin Meyer

-- 
C'ya
        Matthias
________________________________________________________
Matthias Kretz (Germany)                          <><
http://Vir.homeip.net/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030826/3568e747/attachment.sig>