config-aware widgets (was: Re: Experiences with KDE-CVS at LinuxWorldExpo)

[Tim Jansen]

On Monday 11 November 2002 13:52, Marc Mutz wrote:
> Which introduces the need for KConfig(Base) to have change notification
> signals for keys and groups. Something like a KDirWatch for KConfig.

I thought about something like this before, because krfb's situation is pretty 
extreme. There are up to 3 processes running which access the same 
configuration files and try to sync them (the KCM module, the invitation 
creator and the connection handler). 
My current 'solution' is to reload the configuration every 60s in all 
processes and check whether there were any changes. The part is quite 
complicated and error-prone.

You could solve the problem by creating a kded module that controls all access 
to configuration files. Applications can register with the kded module when 
they are interested in a configuration file. Before a KConfig instance writes 
the file, it must 'lock' the configuration file by sending a DCOP message to 
the kded module. The call blocks when another application is currently 
holding a lock. The kded module will then load the configuration itself and 
tell the KConfig to go on. Then the KConfig can modify the configuration 
file. If it is finished, it sends an 'unlock' DCOP message to the kded 
module. The kded module will compare the old configuration with the new 
configuration and sends notifications about the changes to all processes that 
are interested in the configuration file.
This can, BTW, also be used to allow transactions on configuration files. The 
app must then lock the configuration file manually, reload it, modify it and 
unlock it. For krfb it could be useful, because it is possible (even if 
unlikely) that several processes modify the config file at the same time.

bye...