kconfig_compiler problem: no signals on changes

[Richard Smith]

On Friday 12 March 2004 1:40 pm, Cornelius Schumacher wrote:
> On Friday 12 March 2004 13:52, Richard Smith wrote:
> > If we can do without it, it'd be a step backwards from where we are now.
> > We have a couple of toolbar buttons which modify the application
> > settings, and our config dialog is created on demand, so such a solution
> > would certainly not be simple or clean. Also, currently we have different
> > signals being emitted when different sections of the configuration change
> > (the signals aren't emitted until save() is called on the preferences
> > object). So, it'd be much less messy sticking as we are without KConfigXT
> > for now.
>
> You could use different KConfigSkeleton-based classes for the different
> sections of the configuration and reimplement
> KConfigSkeleton::usrWriteConfig() to emit the signal.

Great idea, that does everything we need. Thanks!

One question, though: is there any easy way we can avoid having one .kcfg file 
for each block of options? Is it possible to have, for each group within 
the .kcfg file, a separate class being generated? If not, it's not 
insurmountable; we can add an extra pre-build step to split our kopete.kcfg 
up into chunks.

Thanks,
Richard