-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA384
Howdy,
On Tue, 23 Oct 2018, Yves-Alexis Perez wrote:
On Mon, 2018-10-22 at 23:18 -0400, Unit 193 wrote:
In case you haven't read, Xfconf 4.13.6 brings a new gsettings backend[0]. As
it stands in git right now, the new backend is placed in the 'xfconf' package
which then is marked as providing 'gsettings-backend'. This somewhat diverges
with what the other current backends do, which is provide a new
*-gsettings-backend package.
If we wanted to follow suit of gconf/dconf, we could do so by applying the
patch that is attached. The advantage of doing so is that one can continue to
use xfconf while not using the xfconf gsettings backend as there's no migration
step, while allowing those that wish to get rid of dconf and not have two
settings systems can. The downside of course is having to go through NEW.
Hi, thanks for the summary. Quick questions (some more directed to upstream
maybe):
- 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.
- 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.
- 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.
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. Right now, I'm not sure there's a lot of value in the new
package, but I think it's the most correct thing to do. We might also want to
add a note to the description like gconf does, on how to enable it.
~Unit 193
Unit193 @ freenode
Unit193 @ OFTC
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCQAGBQJbz/yoAAoJEFAB4bCao3RLeNcP/0IpAP479Fsk17OxyaH+mo0R
NrLBxGHhezuCvuGHLQpVK3/pTFzlc/d32qAcwoaGbXoQgs+UIyXv61i/XT7Fo4ky
/g2azyJLMy8+kMGth+q7aOVYKan4Drns5MTBH1563XcbHLgQAu8IpRM+6lpYZNgc
t7CwPLWyIJv6jL+W2SJ8cs9aVeuzbvmZ3C5WNfxi5gHgnsWa8ox/m5QWAUaJj1nu
Qez6RHhpgRqLD1B107SepWa8fOy+1U3DVHhSZvyOoqf9MQERudkb642r8WlHHDY9
swUd6eT9dRTipK+NS2o9Cts6S0LDjrqDrGByrXCXqQulzu/XJUNXebp0csMy9jmi
GF7srdfuIcyhPR9hLHJljfc1YlX81UMPousLT0zY0QIrqTa9VXv57F6CTJ+nN5pT
PNojUFW9Hu7OUCeZj1MB7iRYT+Rv3d9+5ra3uUfQrV/gVxFq0EEyFfX5Mvjan4fp
fVuDDvUF0JHcdl1+beXasLcmQokmne3bU4mb6IPXvuKBSzjwNBWHF/5G55ViQ2qq
6Hd94+aRCUOacwMTpVABR2MVRlZOhhL/cVgFtEhc+NhCfJZxc4LaVqtvYPeVpj1w
aIMvDJFZK2JH/t9YOjDa5Ay//V7iJJ8S57DNpVUFE5iIbW8oZ4QST+c5NvDFxZrT
Ui1tjS2il0iM0+2KgY2O
=Hjj5
-----END PGP SIGNATURE-----
