Status Report for KCall/VoIP

[Malte Böhme]

Hi,

Am Sonntag 24 Juli 2005 13:16 schrieb Eva Brucherseifer:
> Usually KControl is not the place to configure an application. A better way
> is to configure an application from the gui that belongs to the
> application. The reason is, that the user shouldn't need to know about any 
> architecture or framework which makes this difficult to achieve. This is
> why I think that the kcm solution is the worst solution usabilitywise, esp.
> if you add even more kcm modules for each plugin.
Perhaps i wasn't clear enought: you dont configure the plugin through 
KControl!
The kcm is basically a widget that gets loaded into the gui. See 
kcall-tng/kcall/src/kcallgui_part.cpp KCallGuiPart::configure() (around line 
223).

> This is the reasoning behind the configlib in the current kcall version. I
> am unsure though wether there maybe is a better solution. What is so bad
> about sharing a library?
The reason we are doing this whole daemon thing is that the gui does not need 
to know much (if anything at all) about the backend.
with kcm you can simply load the module the backend tells you and dont need to 
know more.


> Another idea was, to extend the plugin api, so that the plugin itself
> communicates which settings it needs to know and the gui displays this.
> Maybe by using an XML description.
I really like the idea and also looked into that, but i dont think i have the 
time to do this during SoC.


maldn