hiding unrelated kcms in project configuration

[Andreas Pakulat]

On 20.12.10 23:16:31, Milian Wolff wrote:
> Hey all,
> 
> right now the project config dialog contains unrelated kcms. In CMake projects 
> it's not obvious until you install qmake, and the qmake builder kcm shows up 
> there. Or in a generic manager the "make settings" are shown. Imo that sucks 
> but I don't quite know how to fix that properly...
> 
> - make is useful for cmake and qmake
> - qmake kcm could be associated with the manager and hence be hidden just like 
> cmake kcm in qmake settings
> 
> wouldn't solve the "make in generic manager" though.

Or the "make in custom-buildsystem" case.

> Ideas?

My personal idea was to drop kcm's. After all the only real benefit we
gain from that here is load/store/defaults functions and a bit on the
dialog-setup parts (but thanks to much work on kdelibs its relatively
easy to setup a similar dialog these days).

Instead we define our own widget-interface that has load/store functions
getting the project->projectConfiguration() and has an API that lets the
plugin decide wether it has something to configure for a given IProject
instance. This could either work by having an extension of IPlugin like

QList<ProjectConfigWidget*> projectConfigWidgets(IProject*) const;

which would return a list of widgets (with name, load/store functions,
id and description). So the cmake plugin for example would return its
own config and asks its build for its config-widgets (via the same API).
The cmakebuilder in turn again asks its internal builder (the make-one)
for its widgets. The id will be used to make sure that there are no
duplicates (as the make-builder might also be asked directly for a
widget).

The other option would be to keep them separate plugins with their own
.desktop files and have a factory-pattern where each plugin can register
a factory instance that has the above API and again works in a similar
way. That way we could keep separate desktop files (and possibly add
special properties if necessary) and still have very little overhead (in
terms of memory) when finding all necessary project-config-widgets.

Andreas

-- 
You may be gone tomorrow, but that doesn't mean that you weren't here today.