xfconf gdbus port (GValue vs GVariant)

flo.xfce at gmx-topmail.de flo.xfce at gmx-topmail.de
Fri Mar 25 01:01:46 CET 2016

I would not say that GSettings is more lightweight than xfconf. Usually
it works together with dconf as backend for persistent storage.
Nevertheless, this would be one module less we have to maintain.
The bigger problem I see with GSettings/dconf is its binary storage.
xfconf comes with xml files and from what I heard in the community this
is considered a big advantage over other settings backends.
Porting to GSettings would be quite a big tasks, nearly every module
currently relies on xfconf.
Regardless I am on Matthew's side. It would be the logical next step
since we're already relying on glib. Independently of how this question
is decided I'd go with Ali's option 2. Probably the Gtk3 port will also
bring API changes.

Kind regards

On 03/24/16 15:41, Matthew Brush wrote:
> On 2016-03-24 02:36 AM, Ali Abdallah wrote:
>> Hello guys,
>> As you may already know, I'm porting xfconf to gdbus for 4.14. I just
>> wanted to share with you some thoughts. Currently libxfconf relies on
>> GValue (an insane decision of dbus-glib bindings...). Obviously it makes
>> more sense to rewrite the internal working of xfconf to rely on GVariant
>> instead, but this implies API changes/deprecations of some symbols. For
>> this I see two options.
>> 1) Keep relying on GValue and convert it to a GVariant each time to send
>> it over the bus-->no API changes.
>> 2) Rewrite the internal working of libxfconf and rely on GVariant -->
>> API changes:
>> /xfconf_channel_set_property/ takes GValue
>>     signal /property-changed/ sends GValue.
>> Option 2.1
>> Deprecate /xfconf_channel_set_property /and provide
>> /xfconf_channel_set_variant/
>> Deprecate /property-changed/ signal and provide a new signal "changed"
>> which sends a GVariant.
>> While I vote for 2.1, I'm okay with any of the above solutions.
> Another more "lightweight" option would be to port applications to use
> GSettings which is already part of GLib/GIO. This way there would be no
> need to have a redundant library, or daemon running.
> Cheers,
> Matthew Brush
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce4-dev

More information about the Xfce4-dev mailing list