xfconf VS libxfce4util Resource Config Files for configuration

[Steve Dodier-Lazaro]

> Not sure what bugs will happen there, the point is it should be
> 'anti-bug' since its only doing what is necessary and isn't touching
> anything vaguely complicated.

Less code = less bugs. The bugs per LoC constant.

> Even in my limited experience as a user here, I've seen a serious
> screwup with this extravagant configuration style - a mousepad config
> change causing infinite dconf traffic spam resulting in serious CPU
> whorage [0] - a problem that has absolutely nothing to do with changing
> a simple configuration value (so 'acceptable bugs' here would be more
> like, 'setting doesn't cause a change' or 'failed to update config file
> due to read-only or disk failure').

That kind of bug is fixed once and forever. It's also noticed faster if you
have multiple apps sharing an API. If I copied your allegedly buggy config
code for my own app and you later fixed a bug in it, I would remain unaware
of the bug in my own app. Someone else would copy my buggy app's code before
I get to fix the bug, and so on...



> You would say, 'but there is more than one instance of the program!',
> and I would say that its understood that you need to restart the program
> to load a new configuration (or that updating configuration in both
> programs will overwrite each other's changes) - thats just a bit of user
> education.

This is NOT an acceptable argument. As a rule of thumb, from a usability
engineer,
if you pronounce the words "user education" you're almost certainly doing
something
shitty. If I have 5-10 instances of gedit or Firefox (yes, I sometimes
do!), all
with various files / objects / websites loaded, with various states (some
of which
not serialisable, e.g. the undo history in gedit or the content of web
forms in
websites), I don't wanna have to close them all, then change my settings,
then
reopen them. It takes a crapload of time to do that, and it's error prone.
If I
forget to close one instance, I might lose the setting change. Worse yet, I
might
not be aware of that, leading to garden-path interaction breakdowns
(
http://methodenpool.uni-koeln.de/situierteslernen/PD%20of%20HCI%20-%20Suchman.htm
)
which might cost me later, when the app behaves in an unexpected way.
Imagine for
instance that I enabled the setting to warn me when I close an unsaved
file/project,
because the keyboard shortcut for closing all current projects is stupidly
easy
to hit in daily use (Firefox's Ctrl+Q next to Ctrl+W for instance). I was
working
on some project for an hour and accidentally hit the bad keyboard shortcut.
I've
lost my work and me resolving the situation after the fact does not repair
the
cost of the breakdown. There are good reasons why a setting must be
immediately
applied, or why I must be VERY RELIABLY assisted in whatever procedure must
be
followed for it to be applied. You need to tell people they have to restart
the
app, and make sure that they can do so without mistake, and without loss of
current
work. I doubt all individual desktop developers will do this properly, as
opposed
to just using the damn Xfconf API and making the problem disappear most of
the time.





> Lots of stuff can be programmed around, but its not worth the
> cost of violating KISS (this is where the care bit comes in, presumably
> most programmers that actually take the time to do this work don't care
> enough about the bloat - 'its normal' - and therefore perpetuate this).

This is not bloat at all, that's the whole point. If you implement half a
correct
settings infrastructure in your app, it'll be as complex as Xfconf is.


> And you shouldn't have to put up with that situation being a possibility
> at all. From my perspective, blaming it on yourself is overlooking the
> absurd overthetopness of the situation. This is a big part of the bloat
> badness - having to be a superstar programmer, having to know everything
> from all over the place inorder to fix/implement a simple thing.

The "superstar" programmer who uses Xfconf needs to write a few dozen lines
of
code in order to manage their settings. The programmer who does it all by
themselves using their "not-superstar" knowledge of UNIX will write hundreds
and hundreds of lines of low-level code, and have tons more error checking
to
do. From my experience, and from evidence found by software engineering
researchers, it's easier to write a few dozens high-level lines with a
really
basic APIs than hundreds of lines of system code. If the API is good, that
is.


> It just sounds like feature bloat - implementing stuff without a serious
> need, and discounting the difficulty/downsides of implementing it when
> 'justifying' the feature.

The bloat is when you have complexity written 50 times by 50 different
developers,
each of which tested in the wild by a single app, rather than something
written
1 time by 1 developer, used 50 times by 50 different developers who
therefore
test it in 50 different ways. Don't implement custom code for settings if
you
can avoid. Xfconf is the least verbose option available to Xfce developers,
ergo
use Xfconf.


> Yeah I lack a word to encompass the 'badness' involved. The 'software
> ethics' stuff from the FSF comes closest to the idea. A recognition that
> a lot of stuff used is overthetop/inappropriate/'bad', and by
> perpetuating it, it takes its toll on resource use, control over the
> code, ability to understand the code used etc.

Xfconf is opensource. All the stuff it uses is opensource. It's better
implemented
than what all joint Desktop app developers can come up with overall if they
all
do their crap in their corner. It's more consistent. It requires less code
loading
overall as it's a shared library. It simplifies code and reduces bugs.
Anyone can
see what it does, how it does it, and fork it if we decide to become evil
and
change Xfconf to spy on users or cause cancer or whatever. Xfconf is not
Mono.
It's not a STD. It's just good software architecture.


Now. I don't care if it's Xfconf or GSettings or Dconf or the new conf
system that
a bored software engineer wrote in between two sessions of making Internet
memes
about goats. As long as there's a single one, that is consistent and
provides *all*
the features that are required for optimal usability, performance and
manageability. So let's choose one and bury the rest please. The whole
"FOSS is
free therefore I refuse to compromise" attitude is nefarious to any FOSS
community
in the long run. I hate GTK+ but I'm happy to read and write GTK+ code for
Xfce,
time provided. Because it helps the community if I suck it up. I believe
the same
should apply for settings handling, error reporting, UI design patterns and
so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20160502/2f585404/attachment-0001.html>