Re: Recommendations for notify usage
- From: Havoc Pennington <hp redhat com>
- To: Nate Case <nd kracked com>
- Cc: gconf-list gnome org
- Subject: Re: Recommendations for notify usage
- Date: 20 Apr 2001 16:13:31 -0400
Nate Case <nd kracked com> writes:
>
> I'm working with an application (Galeon) that contains a lot of
> preferences which seem suitable for the notification feature. For
> example, when the Galeon preferences dialog is configured to use a
> proxy, we need to relay this information to Mozilla.
>
> Is it a bad idea to install individual notify callbacks for many keys?
> I have generalized the notify callbacks when possible so that they can
> be used for multiple GConf keys, but I still get the feeling that
> performance could suffer with so many gconf_client_notify_add() calls.
>
> Sorry if I'm missing something fundamental here, as this is my first
> time using GConf in a non-trivial application.
>
Using GConfEngine, each notification you add is added on the server
(gconfd). However, with GConfClient, if you add a directory with
gconf_client_add_dir(), then only one notification is installed on the
server (for the directory) and adding a notification for a key inside
that directory is extremely cheap. However, the penalty is that the
server notifies your process of all changes in that directory.
Anyway, basically the way it's intended to be used is:
- you have all your keys in a directory or directories belonging to
your app (the GConf docs tell you what to name these directories)
- you add that directory to GConfClient
- you then add a bunch of notify callbacks for each setting you want
to monitor
You can also just add a notify for a directory, and write a big:
if (strcmp (key, "/foo") == 0)
;
else if (strcmp (key, "/bar") == 0)
;
type of stuff in your callback, but IMO that is kind of sucky.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]