<div dir="ltr">I should state that I also agree to GNOME being a dislikable upstream (and three years from now someone will probably give me a printout of this email and poke fun at me for it, damn). Yes, upstreams are people that we depend on and so it means we must trust them not only to provide reliable software now but also in the future. I do not trust GNOME/GTK+ with that given all that has happened with the themes in the past few years, and that's why I proposed switching to Qt as an upstream. We've made a decision already years ago about that - which I fully support now because we're a team - and we will pay the consequences of it no matter what happens in the future. It's unlikely that a panel plugin not making that commitment of trust makes a difference in that regard if we need to change upstreams in the future. It is however very likely that said plugin not adopting a coherent / joint code base with the other Xfce code bits will complexify maintenance on a daily basis and force us to maintain a wider range of expertise on the code base. I would have preferred working on a C++ / Qt code base or even on a plain C / GTK+2 code base, but that's not possible and so we shouldn't hold back and create more complications in the future.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 1 May 2016 at 16:58, 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"><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><div class="h5"><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></div></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>