Matthias Kretz kretz at kde.org
Sun Jun 23 20:49:24 BST 2002

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

- -- 
Matthias Kretz (Germany)
MatthiasKretz at gmx.net, kretz at kde.org
Version: GnuPG v1.0.7 (GNU/Linux)


More information about the kde-core-devel mailing list