Re: Xfconf's new gsettings backend
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA384
Howdy,
On Wed, 24 Oct 2018, Yves-Alexis Perez wrote:
On Wed, 2018-10-24 at 01:01 -0400, Unit 193 wrote:
- it seems that the gsettings backend is not used by default, at least for
now; any idea if it'll be mandatory in the future?
I'd hope that it'd be on by default in 4.14, but this I cannot say for sure. I
would expect it wouldn't be required, since there's a compile time option to
disable it.
It'd be interesting to know that in order to make a decision whether to enable
it or not.
I talked with the upstream maintainer briefly and as far as he was aware there
wasn't a way to actually enable the Xfconf backend without setting the env var,
and that'd been the only way I'd found to enable it as well.
- when enabled, that means all gsettings can be stored through xfconf, using
whatever xfconf storage backend is (currently .xml files in
.config/xfce4/xfconf/xfce-perchannel-xml), is that right?
This is correct, right now gsettings uses dconf as a backend, so you end up with
at least two daemons.
But when enabled in xfconf, does xfconf handle *all* gsettings setting, and
nothing ends up in dconf?
Correct, you can entirely remove dconf without any issue regarding gsettings.
- when starting to provide a gsettings backend, how will interactions with
other backend be handled? Can two backends run concurrently? Is there some
kind of migration from one backend to another?
As Xfconf is not enabled by default right now and you must use
GSETTINGS_BACKEND=xfconf, I am fairly confident that gsettins will only push to
one backend. As they are backends, there isn't really any migration.
I might have been unclear, sorry. When gsettings backend is enabled in xfconf
(whether with the current env var, or in the future if it's enabled by
default), what happens if two gsettings backends are installed/enabled (xfconf
and dconf)? Do they fight? Should we conflict against other gsettings backend?
If so, how is the migration handled?
Since the env var is set, gsettings just forwards everything to the defined
backend, which would be Xfconf. I don't see a reason one must have them
conflict in this case.
As the backends aren't aware of eachother, you would have to dump dconf and
import to xfconf.
In any case, those questions are really meaningful when we start enabling it
by default, which is not the case right now. If the only drawback to splitting
the backend to a different package is that it has to go through NEW, then no
issue for me.
That would be one reason to ship the backend in another package once xfconf's
backend is enabled by default, the lack of migration and need to reset some
configuration values.
Does this mean we'll lose any gsettings parameter stored in dconf? I don't
think it's acceptable.
As mentioned above, yes. I suppose that could be another reason to ship it in
another package, but I'd be interested in making it easier to enable. I presume
you'd be against injecting the setting into the user's environment if
xfconf-gsettings-backend is installed?
I did test what would happen if the env var was set to Xfconf and it wasn't
installed, gsettings gracefully fell back to using dconf with a warning message
to the console. If neither dconf nor xfconf are installed (unlikely as packages
depend/recommend a backend) then the 'memory' "backend" is used. Note that the
'memory' backend takes priority to the 'xfconf' backend, so one can't just
remove dconf.
~Unit 193
Unit193 @ freenode
Unit193 @ OFTC
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCQAGBQJb030SAAoJEFAB4bCao3RLHeYP/RwXAkc0FHhClCMyxkjGdLRA
SpFK3Tgwm6vwzL77n7RFP9I5E8avRP3BYgqGVlJ7oaqeVqOuuSk8vEq9UEasaS+S
DkiTYGMAQAjc9jXQhlE/h+otmsKyRd780YT5Ca2qBnNgb6DR9b/6D4/aeX+tzkys
vZpZIvViq5JkAuQ0oegGQywCdH6ulhZtNrW15VIr9bng/YZLCur6Qmj/y5tU7Pwj
jg7thgbbaxDPxX5Pt8sKxgep8LaYfse+r+ZVcT1HFvntwVXqjZZdWwvASddp46fB
Ig1WihXnUYtHpnU0WqWniIg4lKqv0qpQ0zjCwaeSD/Tbm4WUs+EF4WMXEUj0k4eb
hsmaEdr+mV0IxJHP++ojtqoeeU4dpuKABSPQu0b4pBWee3lgqohaHk5wruHgAogC
RJ+oduWh0fkVtGfSSmIO9W73wYKdLqbTDa0MnYmqG5X73LCa4002JswRrE3I39zd
tUdkGYHNF/5zHPqMX5edd6xMMJSPWSTWIm0Z67ektPi8NJeCAVK9BfzEkcHTtfx3
3nrn5P8ejKyjKCiG4lBZBxLt9PtosAXjeGbIIG4zydbuL8gFR/PL/MQOus4sUrSV
UshQUkX+A58Tbznry5KXU48QgMeetmt9wmozZd4tp3qDCSNwXeqcDvix+DUYRLEV
4/Yze0smI/8x/k9ssnDP
=S1lN
-----END PGP SIGNATURE-----
Reply to: