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