[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