xfconf VS libxfce4util Resource Config Files for configuration

[Steve Dodier-Lazaro]

I forgot part of my code changes in the previous patch. Use
http://paste.fedoraproject.org/363539/57478514/ instead. I am running the
panel with a GKeyFile backend for module loading right now.

I've looked at how XfceRc works compared to GKeyFile and there are a few
main differences:
- XfceRc interfaces with XfceResource to automatically load config files
from the best place
- XfceRc has a more advanced mechanism for saving user changes (with pros
and cons)
- XfceRc has a "rollback" mechanism to avoid saving changes done previously
(which is semantically incorrect actually, and which seems unused in the
code base)

There are multiple options:
- keep using XfceRc, prevent 3rd-party apps from using GKeyFile on files we
open with XfceRc (to avoid issues with syntax variations); inconvenient for
things like .desktop files in cross-DE setups
- use GKeyFile as is, inconvenient is we'll have to add quite a bit of code
to all our apps to find where to load GKeyFile from and for file saving
- develop a XfceKeyFile API which internally uses GKeyFile, provides some
of the API advantages of XfceRcConfig and deprecates some other, less used
features like rollback. People can use GKeyFile and transparently switch to
XfceKeyFile if they need the extra feature in the future. We have a strong
guarantee that files are loaded and saved in the same way between both
APIs. We also have less code to maintain in the long-term. This is most
similar to our GIO and GTK extensions and is my favourite approach.

There's also another issue where I'd like some advice. Currently
XfceRcConfig will only save in the user directory the bits that changed
from the file in /usr, /etc or whatever (see for yourself with attached
file that hides Ristretto). That's nice because if we change the default
value of something that was not user-explicitly set in the future, then
users' modified apps will benefit from the change in the default .desktop
file. That's also kinda crap because it means we produce standalone
.desktop files which are semantically incorrect, and which will be loaded
in priority by third-party APIs like GDesktopAppInfo and whatever KDE is
using.

So if you know more about this feature, would you be able to tell just how
much benefit it brought it? How important has it been in the past that we
were able to do that? It does significantly complicate the existing API and
the one I propose to write and it could cause cross-DE compat issues.

Cheers,

On 6 May 2016 at 12:02, Steve Dodier-Lazaro <sidnioulz at gmail.com> wrote:

> http://paste.fedoraproject.org/363348/62532504 for the main panel-module
> port. Am in plane, will look up the rest later.
>
> On 6 May 2016 at 08:34, Landry Breuil <landry.breuil at gmail.com> wrote:
>
>> On Mon, May 2, 2016 at 8:53 PM, Steve Dodier-Lazaro <sidnioulz at gmail.com>
>> wrote:
>> > Woops, missing the first part of the novel I just wrote. This reads
>> *before*
>> > the previous email :D
>>
>> <snip> TL;DR (almost) You have many points/arguments, but think of how
>> much code could have been written/ported in the time it took you to
>> write all this :)
>>
>> > WHICH BRINGS ME TO THIS DESPERATE CRY: CAN WE PLEASE BURN XFCERC TO THE
>> > GROUND AND
>> > USE GKEYFILE LIKE RESPONSIBLE SOFTWARE DEVELOPERS!? Thanks *insert your
>> > favourite
>> > emojis here for added dramatic effect*
>>
>> Sure. All panel plugins use XfceRc. Who's gonna provide a common
>> migration path/code from XfceRc to GKeyFile ?
>> You surely don't want all your users to suddenly lose their panel
>> plugin settings.....
>>
>> Landry
>> _______________________________________________
>> Xfce4-dev mailing list
>> Xfce4-dev at xfce.org
>> https://mail.xfce.org/mailman/listinfo/xfce4-dev
>>
>
>
>
> --
> Steve Dodier-Lazaro
> PhD Student
> University College London
> Free Software Developer
>



-- 
Steve Dodier-Lazaro
PhD Student
University College London
Free Software Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20160507/b6316a52/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-rc-flush.c
Type: text/x-csrc
Size: 1061 bytes
Desc: not available
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20160507/b6316a52/attachment.c>