From kde-devel Wed Jun 03 21:39:36 2009 From: Milian Wolff Date: Wed, 03 Jun 2009 21:39:36 +0000 To: kde-devel Subject: Re: KCM and KConfigXT Message-Id: <4A26ED98.1000209 () milianw ! de> X-MARC-Message: https://marc.info/?l=kde-devel&m=124406526420190 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 <<