I wrote a plugin for the wayfire wayland compositor, which uses gsettings to store it’s setting.
On key-press g_settings_set_uint(...) is called which results in the G_CALLBACK(…) to be called and dconf-editor / gsettings to reflect those changes.
Although when setting that same property via either gsetting/dconf cli or dconf-editor the G_CALLBACK(…) is not called.
I can only imagine that this is because the compositor the first process in that session, as I have verified the “changed” signal to not be working as well with “ca.desrt.dconf-editor.Settings”
I verified that the DBUS_SESSION_ADDRESS is already set correctly.
/usr/lib/dconf-service is already running.
All the signals are emitted if monitored via dconf watch /
Glib 2.64.4
I prefer to use gsettings instead of the compositor’s own wf-config and appreciate your suggestions.
Read the small print in the docs for Gsettings::changed - the signal is only emitted after you’ve read the key at least once. The theory is that you are probably not interested in changes if you didn’t know the old value in the first place.
@matthiasc Yes, It has been read beforehand. And also the changed signal works if the
plugin itself uses g_settings_set(…) but if the origin is not the plugin the changed signal is never emitted.
but did you try doing what the documentation suggests, and explicitly read the value once, at the time that you establish the monitor ?
I interpret the documentation that once I have used g_settings_get(…) on the value,
it starts monitoring, yes I’ve tried that before and updated it on github to explicitly reflect that.