The "writable-change-event" signal is emitted once per writability
change event that affects this settings object. You should connect
to this signal if you are interested in viewing groups of changes
before they are split out into multiple emissions of the
"writable-changed" signal. For most use cases it is more
appropriate to use the "writable-changed" signal.
In the event that the writability change applies only to a single
key, @key will be set to the #GQuark for that key. In the event
that the writability change affects the entire settings object,
@key will be 0.
The default handler for this signal invokes the "writable-changed"
and "changed" signals for each affected key. This is done because
changes in writability might also imply changes in value (if for
example, a new mandatory setting is introduced). If any other
connected handler returns %TRUE then this default functionality
will be suppressed.
The "writable-change-event" signal is emitted once per writability change event that affects this settings object. You should connect to this signal if you are interested in viewing groups of changes before they are split out into multiple emissions of the "writable-changed" signal. For most use cases it is more appropriate to use the "writable-changed" signal.
In the event that the writability change applies only to a single key, @key will be set to the #GQuark for that key. In the event that the writability change affects the entire settings object, @key will be 0.
The default handler for this signal invokes the "writable-changed" and "changed" signals for each affected key. This is done because changes in writability might also imply changes in value (if for example, a new mandatory setting is introduced). If any other connected handler returns %TRUE then this default functionality will be suppressed.