[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KCM and KConfigXT
From:       Milian Wolff <mail () milianw ! de>
Date:       2009-06-03 21:39:36
Message-ID: 4A26ED98.1000209 () milianw ! de
[Download RAW message or body]

Andreas Pakulat wrote:
> On 03.06.09 19:26:31, Milian Wolff wrote:
>> Hi fellow devels!
>>
>> I'm trying to make a KDevelop plugin (php-docs in playground) 
>> configurable by writing a KCM module for it (which is then integrated 
>> into KDevelop).
>>
>> I thought KConfigXT is to be used since it can take a bit of work from 
>> the developer. Right now I think this assumption was wrong:
> 
> I don't think your assumption was wrong.
>  
>> 1) It looks like KConfigXT bears no real advantages when used in a KCM. 
>> I.e.:
>>
>> - I have to implement load(), save() and defaults(). Currently I do it 
>> like this:
> 
> No you don't. Look at the other kcm's we have in KDevelop, for example
> kdevelop/projectbuilders/makebuilder. You need however to name the
> objects in your ui file with a kcfg_ prefix.
> 
>> - I have to manually connect some signals to notify about changed state
> 
> That should work for most standard widgets, but indeed not all are
> supported in the way you may want them by KConfigXt (or more precisely
> KConfigDialogManager).

It is strange: The whole stuff works if I put the UI in a child-widget 
of the KCM... See my bugreport:

https://bugs.kde.org/show_bug.cgi?id=195151

>> 2) Is the KConfigSkeleton generated by KConfigXT supposed to be used 
>> across binary targets? I thought it would be nice to use it in the KCM 
>> and in the real plugin with it's nice Singleton structure and esp. it's 
>> automatically generated accessors.
>>
>> Problem is that currently I get pointers to two different 
>> KConfigSkeletons from the Settings::self() method. I think that is due 
>> to the generated KConfigXT files being linked to both plugins directly. 
>> I'd have to put it into some shared library or something. Overkill?
> 
> If its just the skeleton in the shared lib, then IMHO yes its overkill.
> Especially since those settings are usually quite easily accessible
> (unless you start with tons of subgroups) If you also have other things
> to put into the shared lib that might be different...

Yeah, I think so as well. Will use the method as you wrote below:

>> So my question is: Can I get it to work or should I just drop KConfigXT 
>> and read the settings in the KCM and the plugin separately? I heard that 
>> there is some kind of config-dispatcher class I can connect to which 
>> notifies my about changed configuration values.
> 
> That would be KSettings::Dispatcher in kutils library, you can register
> a qobject+slot name and supply the component name of the kcm you want to
> get notified when it changes.

I now use that and update the KConfigSkeleton in the not-kcm plugin via 
PhpDocsSettings::self()->readConfig().

In my KCM I do a writeConfig() and then tell the dispatcher to reparse 
the configuration. Works great. Thanks!

-- 
Milian Wolff
http://milianw.de
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]