<div dir="ltr"><div class="gmail_quote">Xfce4util uses the GLib, which is maybe not 90% of the codebase but definitely 90% of the complexity of Libxfconf's dependencies. Bugs in XML parsers are easy to test for / detect. Recursive GObject dependencies and GType init race conditions are an absolute pain in the *** to detect, reproduce, debug and fix. I threw away months worth of code on Unity because their software is too crippled for me to efficiently debug whatever atrocities they are doing to GType / GObject.<br><br></div><div class="gmail_quote">So if you want simpler, KISS-er libraries I propose we throw the baby with the bath water and reimplement Xfce in C++. Then we can get rid of GObject. Otherwise since we're already in on it and already suffer all the programming style inconvenients, alleged bloatedness and memory usage of GTK+ / GIO / GLib, we might as well use it in full to delegate most of the API testing to the GNOME folks (who unlike us are sponsored by a multi-million dollar company full of good software engineers), and just write as little code as we need. Xfconf is in my opinion better in design than GSettings because it integrates better with user tools and demands, but XfceRC should really be a thing of the past. We already have GKeyFile (already integrated with GDesktopAppInfo) and Xfconf. When I have to modify Xfce apps for my downstream projects, having to deal with XfceRc / GKeyFile conversions between different bits (Exo, Xfce4Util, Xfce4UI, Garcon) is plain annoying.<br><br></div><div class="gmail_quote">Anyway, just my personal opinion :-)<br></div><div class="gmail_quote"><br>On 30 Apr 2016 14:24, "OmegaPhil" <<a href="mailto:OmegaPhil@startmail.com" target="_blank">OmegaPhil@startmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I understand if you don't want to discuss this, but continuing:<br>
<br>
Can't you implement a hierarchy by using structure in INI section<br>
titles/groups, e.g. 'Default/DVI-0', also can be used in the settings<br>
names themselves?<br>
<br>
I get the feeling its not so much 'needs' but programmer 'wants', to<br>
make things convenient to program etc, without paying attention to the<br>
cost of its actual implementation ('oh look this random library/system<br>
has already been created that has all sorts of bells and whistles, just<br>
use that!'). Simplicity is supposed to be extremely important for<br>
resource usage, debugging, control, etc.<br>
<br>
GSettings uses XML and compiled schemas (!!!), and looks to be another<br>
programming frontend to god knows what (I'm seeing 'backend' and dbus<br>
mentioned in places), so definitely fails KISS.<br>
<br>
<br>
On 30/04/16 12:47, <a href="mailto:flo.xfce@gmx-topmail.de" target="_blank">flo.xfce@gmx-topmail.de</a> wrote:<br>
> The big advantage of xfconf is hierarchical storage. Just have a look at<br>
> xfce4-settings-editor - how would you transform the display channel or<br>
> xfce4-panel channel settings into an rc file? (Nevertheless an rc file<br>
> can also be a valid choice, especially for plugns, which usually have<br>
> only a few settings).<br>
> The point here is: Different applications have different needs when it<br>
> comes to settings storage. You can either use a big complex backend<br>
> which tries to address all those needs or multiple lightweight backends.<br>
> Have you looked at GSettings? Maybe its more to your liking.<br>
><br>
> Kind regards<br>
><br>
> On 04/30/16 12:56, OmegaPhil wrote:<br>
>> I'm the maintainer of the XFCE4 Hardware Monitor Plugin [0], and I'm<br>
>> currently reviewing how I maintain configuration for the plugin.<br>
>><br>
>> At the moment I use libxfce4util's rc file functionality, but I don't<br>
>> like the separation between reading and writing when you open an rc file<br>
>> (reading something and potentially writing a change based off that is a<br>
>> normal thing).<br>
>><br>
>> xfconf appears to offer a more regular read/write approach (haven't<br>
>> tried it yet), but looking into its implementation, immediately fails on<br>
>> KISS (Keep It Simple Stupid) - hugely bloated - XML, DBus, GObject,<br>
>> probably other stuff I'm not aware of. The task is just to store and<br>
>> retrieve a few bits of data into a simple text file, which is the UNIX way.<br>
>><br>
>> I'm aware of xfconf's ability to store more complicated data and a<br>
>> hierarchy of data, but I don't need this. There is also the catch that<br>
>> XFCE4 has already paid the price for the bloat, however that doesn't<br>
>> dictate whether I should support it or not ('ethics').<br>
>><br>
>> Does anyone here have serious usage of xfconf, and can bring up good<br>
>> reasons for using it over a normal configuration file?<br>
>><br>
>> Thanks<br>
>><br>
>><br>
>><br>
>> 0:<br>
>> <a href="http://goodies.xfce.org/projects/panel-plugins/xfce4-hardware-monitor-plugin" rel="noreferrer" target="_blank">http://goodies.xfce.org/projects/panel-plugins/xfce4-hardware-monitor-plugin</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<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><br>
>><br>
> _______________________________________________<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><br>
><br>
<br>
<br>
<br>_______________________________________________<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><br></blockquote></div>
</div>