See bug 730886 for some examples of why this is an issue.

More generally, quite a lot of classes these days are implemented in a pretty consistent way, with their property set function looking like:



  switch (prop_id)
    {
    case PROP_ONE:
      my_obj_set_one (obj, g_value_get_thing ());
      break;
    case PROP_TWO:
      my_obj_set_two (obj, g_value_get_thing ());
      break;
    case etc:

ie: always calling the public accessors.

Those functions, because they are public C API, always emit "notify" in case of changes.  It is common practice, however, to avoid setting the value (and avoid the notify) in the case that the value being set is the same as what was already there.

g_object_set() always emits notify on the property in question, even in the case that the class didn't do it for itself.

We should have some mechanism by which classes can indicate to GObject that this is not desired.

A few possibilities present:

 - have a call that the user can make during a set_property invocation which
   tells GObject to skip the emission

 - have a flag that can be set on the type at class_init() time to prevent
   notify by being emitted on properties of this class

 - have a flag on the paramspec


From an implementation standpoint, a flag on the paramspec would be cleanest.  It's a bit annoying to use, however: we would be adding one more "flag that you always want to use" (eg: G_PARAM_STATIC_STRINGS).

The "skip emission" call is conceptually ugly.

The per-class flag is an interesting thought.  In fact, we could introduce a per-class GParamFlags that gets OR'd into all GParamSpec installed onto this object.  We could also just make a convention that having a

#define MY_PARAM_FLAGS  (G_PARAM_STATIC_STRINGS | G_PARAM_NO_NOTIFY)

and using that is "standard practice", but that's a bit weak...