kdelibs/kdeui

Martijn Klingens klingens at kde.org
Sun Jun 23 19:44:24 BST 2002


On Sunday 23 June 2002 20:20, Cristian Tibirna wrote:
> 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.

I think the same.

BUT: It would be a pain to implement this in e.g. Kopete, because it can slow 
the application down to a crawl, because all plugins have to be loaded, just 
for the settings page.

> Of course, this is not always viable (e.g. plugins that get
> produced/distributed separately from the app - the case of konqueror, BTW).

Not true. After the installation of a plugin there's another set of options, 
which will be there until you uninstall the plugin from your harddisk. Same 
problem as above: memory requirements and loading time, but technically no 
problem.

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

That's another option, but in case of plugins in categories that's still a bit 
ugly. Better then would be something like

+- Playlists
|   +- Foo
|   +- Bar
+- Visualizations
|   +- Blah
|   +- Bluh

etc.

Martijn





More information about the kde-core-devel mailing list