[Panel-devel] on KConfig::sync() usage

Aaron J. Seigo aseigo at kde.org
Wed Jan 2 00:13:21 CET 2008


hi everyone =)

today i added a signal to Applet: configNeedsSaving(). i've also replaced all 
occurances of the equivalent of config()->sync() that i could find with it. 
the reason is that applets should never, ever call sync() directly. why not?

* it can easily result in multiple disk writes when only one is really 
necessary. an interesting example would be the notes app where it would 
sync() the config on both apply and ok being clicked in its config dialog. 
it's not unusual for users to click Applet then Ok (watching users can be 
fascinating ;) which could result in *two* writes happening one after the 
other. another example is whenever a number of applets are changed in quick 
succession ...

* it can cause disk activity at bad moments; for instance, the notes app (to 
pick on it again ;) was sync'ing on constraintsUpdated. always. every time. 
ugh!

* it makes assumptions about the saving of config files that may not hold true 
on all devices that plasma applications end up on. 

* it makes it impossible to set saving policies, e.g. "delay saves even more 
aggressively when on battery, but instantly on power critical notification" 
or "save once we have accrued N save requests within X time period" or 
whatever we might dream up.

* it makes assumptions about what lies behind config() and globalConfig(). it 
was somewhat common to see the rather scary config()->config()->sync(); 
there's a at least one hidden assumption there, namely that config() and 
globalConfig() exist in the same file. sure, they do now. but they didn't 
used to and one should never assume such things.

in short ... do not ever call sync() from your applet or containment. instead 
emit the configNeedsSaving signal.

questions, comments?

p.s. on a related note: *never* hold on to the value of config() or 
globalConfig(). some applets were storing it as a member variable in one of 
their classes! since the config file can actually *change* at runtime, this 
is obviously a bug just waiting to happen.

p.p.s. i wish the KConfig itself provided a way to get notified of it's dirty 
status changing so that even this code wouldn't be necessary, but it 
doesn't .. so ... yeah.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080101/ed90a52b/attachment.pgp 


More information about the Panel-devel mailing list