xfconf VS libxfce4util Resource Config Files for configuration
OmegaPhil
OmegaPhil at startmail.com
Mon May 2 18:32:14 CEST 2016
On 02/05/16 15:05, Matthew Brush wrote:
> As a counter example, Geany (another app I contribute to) uses plain
> GKeyFiles and it's kind of a nightmare trying to work in multiple
> instances. You have to always be sure to close the instances in the
> correct order depending on what settings/sessions you want to be saved
> or else you lose settings, clobbered by the last closed instance. Also
> it has a whole code module (file) that tries to duplicate the
> widget/object binding provided by GLib/GSettings/Xfconf, which is
> confusing and not that many developers even understand it. Also, you
> can't really edit its own config file in itself because if you do, when
> you close it, it overwrites the changes you just made. It has a special
> case hack in its code to try and work around this by detecting if the
> file being saved is its own config file, but it doesn't seem to work. It
> even has a special menu item to reload configuration file, but it
> doesn't completely reload all configuration because some of it is only
> on code paths reached at startup. All in all, if Geany was re-written to
> use something like GSettings, barring any new bugs introduced in the
> process, it would eliminate loads of complicated, redundant,
> bug-report-causing code.
OK, I understand that an IDE can warrant some complexity in marshalling
configuration, only as multiple complicated projects open at once is not
unusual. Personally I wouldn't use that as justification for dbus and a
dedicated daemon, it should be dealt with between the instances
themselves (no idea how, finer-grained locking of data/files? Inotify?
Pipes? etc. It makes me think 'database', so only sqlite would be
appropriate here barely, but that won't do notification).
I would agree in general that you shouldn't be able to edit a program's
config file while its running, and definitely not reload a configuration
at runtime. That is feature bloat that has resulted in a buggy
implementation, pushing towards dependence on the library implementation
you mention as the 'correct answer'. I'd stop at that point and remember
that Geany is supposed to be a 'lightweight GUI text editor' :p
> It's important not to confuse programming bugs with problems of
> "extravagant" configuration systems. That is a bug I introduced because
> I'm a bad programmer, not because GSettings is
> bad/extravagant/bloated/whatever.
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.
>> 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. 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).
>
> See above about Geany, it's an example where the supposed KISS way ends
> up causing lots of overly-complicated code in the app, and weird
> sequencing bugs that even still trips me up, as a long-time user, and
> developer, fully aware of the problems. You can't really escape the
> complexity, you can only choose whether you make your own mess, or you
> use the mess someone else maintains.
It just sounds like feature bloat - implementing stuff without a serious
need, and discounting the difficulty/downsides of implementing it when
'justifying' the feature.
>> And the ever-attractive 'sunk cost' argument, the bloat is already there
>> so why not embrace it? Thats where the ambiguous 'ethics' thing comes
>> in, I don't use proprietary software just because its there, or even
>> when it makes up the bulk of something - its still bad, and something to
>> be avoided/not to be encouraged. Makes for an easier escape when the
>> time comes to get out of the 'bad thing'.
>>
>
> Actually re-using code other people wrote and maintain is a
> long-standing best practice in software (especially FOSS). At some point
> if you roll your own system, it will eventually re-invent the wheel
> someone else has already written, debugged and optimized, and you'll be
> left with wads of inefficient, bug-laden code that is specific to your
> application.
>
> There's nothing unethical about re-using libraries people already wrote.
> You could consider rolling your own when there's something already
> pre-written and loaded into memory unethical, I suppose, though I
> wouldn't use such a strong term for this.
No no, not reinventing the wheel - just drawing the line and not
implementing/using stuff in the first place. Don't do it 'just because
its there'/someone else is, or 'because it would be nice/there is a want
to do something'.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20160502/05b02beb/attachment.sig>
More information about the Xfce4-dev
mailing list