kdelibs/kdeui
Matthias Kretz
kretz at kde.org
Sun Jun 23 20:49:24 BST 2002
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 23 June 2002 20:20, Cristian Tibirna wrote:
> On Sunday, 23 June 2002 12:58, Matthias Kretz wrote:
> > Plugin configuration is different though. In my opinion the configuration
> > page of a dialog shouldn't ever appear if the plugin is not used
> > (loaded). Imagine a user opening that page configuring it and then he
> > wonders why it doesn't work.
>
> In my own user experience (humble and probably very specific to my
> computing habits), having a flat set of configuration options change
> depending on what plugins are loaded or not is confusing and irritating. I
> prefer by far that a placeholder (e.g. the plugin's options disabled) is
> always present in the configuration set of the app that can load that
> plugin.
So the Noatun and the Kopete Configuration Dialog confuse you? Interesting.
Their behaviour was exactly the way I expected the plugin configuration to
work - without ever thinking about it before. (And I just asked a friend and
he thinks the same.)
The biggest problem is, that the app doesn't know anything about the plugin
except it's name, author and how to load it. How could the app know anything
about a configuration dialog for a plugin. This would require an app to load
all plugins - which IMHO defeats part of the purpose of plugins.
> Of course, this is not always viable (e.g. plugins that get
> produced/distributed separately from the app - the case of konqueror, BTW).
> In this case, the plugin config modules should be included as children of a
> "root" entry in the flat set of configurations of the app, "root" that
> would be called (bluntly) "Plugins Configurations". This would present, in
> a branched tree, again, the list of plugins loadable (with ckeckboxes)
> and, for all loaded plugins, their respective configuration pages.
Do you think this should appear in the TreeList of the KDialogBase? I don't
think that would be a good idea (the checkboxes in the TreeList). And I'm
against loading the plugins before the user decides to use them. So the app
doesn't know if the plugin has one (or more) configuration pages and therefor
can't show anything in advance.
Another idea I could (almost) live with: On the plugin selection page we could
add a button "Configure Plugin" which would open yet another dialog - that's
why I prefer the other idea - showing the plugins configuration dialog.
If that's the common opinion I want to have a configuration option (half
joking here):
o Use dynamic configuration dialogs
o don't change my dialogs
;-)
- --
C'ya
Matthias
________________________________________________________
Matthias Kretz (Germany)
http://Vir.homeip.net/
MatthiasKretz at gmx.net, kretz at kde.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9FiZEyg4WnCj6OIoRAvDoAJ0YjQCZsGJeObCvkRp0z1NOi3KSbgCg35MJ
p9a7l7FwSi1FnBnvfrhfAbY=
=dyWf
-----END PGP SIGNATURE-----
More information about the kde-core-devel
mailing list