<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div>I forgot part of my code changes in the previous patch. Use <a href="http://paste.fedoraproject.org/363539/57478514/">http://paste.fedoraproject.org/363539/57478514/</a> instead. I am running the panel with a GKeyFile backend for module loading right now.<br><br></div>I've looked at how XfceRc works compared to GKeyFile and there are a few main differences:<br></div>- XfceRc interfaces with XfceResource to automatically load config files from the best place<br></div>- XfceRc has a more advanced mechanism for saving user changes (with pros and cons)<br></div>- XfceRc has a "rollback" mechanism to avoid saving changes done previously (which is semantically incorrect actually, and which seems unused in the code base)<br><br></div>There are multiple options:<br></div>- 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<br></div>- 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<br></div>- 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.<br><br></div>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.<br><br></div>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.<br><br></div>Cheers,<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 6 May 2016 at 12:02, Steve Dodier-Lazaro <span dir="ltr"><<a href="mailto:sidnioulz@gmail.com" target="_blank">sidnioulz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><a href="http://paste.fedoraproject.org/363348/62532504" target="_blank">http://paste.fedoraproject.org/363348/62532504</a> for the main panel-module port. Am in plane, will look up the rest later.<br></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On 6 May 2016 at 08:34, Landry Breuil <span dir="ltr"><<a href="mailto:landry.breuil@gmail.com" target="_blank">landry.breuil@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Mon, May 2, 2016 at 8:53 PM, Steve Dodier-Lazaro <<a href="mailto:sidnioulz@gmail.com" target="_blank">sidnioulz@gmail.com</a>> wrote:<br>
> Woops, missing the first part of the novel I just wrote. This reads *before*<br>
> the previous email :D<br>
<br>
</span><snip> TL;DR (almost) You have many points/arguments, but think of how<br>
much code could have been written/ported in the time it took you to<br>
write all this :)<br>
<span><br>
> WHICH BRINGS ME TO THIS DESPERATE CRY: CAN WE PLEASE BURN XFCERC TO THE<br>
> GROUND AND<br>
> USE GKEYFILE LIKE RESPONSIBLE SOFTWARE DEVELOPERS!? Thanks *insert your<br>
> favourite<br>
> emojis here for added dramatic effect*<br>
<br>
</span>Sure. All panel plugins use XfceRc. Who's gonna provide a common<br>
migration path/code from XfceRc to GKeyFile ?<br>
You surely don't want all your users to suddenly lose their panel<br>
plugin settings.....<br>
<span><font color="#888888"><br>
Landry<br>
</font></span><div><div>_______________________________________________<br>
Xfce4-dev mailing list<br>
<a href="mailto:Xfce4-dev@xfce.org" target="_blank">Xfce4-dev@xfce.org</a><br>
<a href="https://mail.xfce.org/mailman/listinfo/xfce4-dev" rel="noreferrer" target="_blank">https://mail.xfce.org/mailman/listinfo/xfce4-dev</a></div></div></blockquote></div><br><br clear="all"><br></div></div><span class="">-- <br><div><div dir="ltr"><div>Steve Dodier-Lazaro<br>PhD Student<br>University College London<br>Free Software Developer<br></div></div></div>
</span></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div>Steve Dodier-Lazaro<br>PhD Student<br>University College London<br>Free Software Developer<br></div></div></div>
</div>