<div dir="ltr">> Not sure what bugs will happen there, the point is it should be<br>> 'anti-bug' since its only doing what is necessary and isn't touching<br>> anything vaguely complicated.<br><br>Less code = less bugs. The bugs per LoC constant.<br><br>> Even in my limited experience as a user here, I've seen a serious<br>> screwup with this extravagant configuration style - a mousepad config<br>> change causing infinite dconf traffic spam resulting in serious CPU<br>> whorage [0] - a problem that has absolutely nothing to do with changing<br>> a simple configuration value (so 'acceptable bugs' here would be more<br>> like, 'setting doesn't cause a change' or 'failed to update config file<br>> due to read-only or disk failure').<br><br>That kind of bug is fixed once and forever. It's also noticed faster if you<br>have multiple apps sharing an API. If I copied your allegedly buggy config<br>code for my own app and you later fixed a bug in it, I would remain unaware<br>of the bug in my own app. Someone else would copy my buggy app's code before<br>I get to fix the bug, and so on...<br><br><br><br>> You would say, 'but there is more than one instance of the program!',<br>> and I would say that its understood that you need to restart the program<br>> to load a new configuration (or that updating configuration in both<br>> programs will overwrite each other's changes) - thats just a bit of user<br>> education.<br><br>This is NOT an acceptable argument. As a rule of thumb, from a usability engineer,<br>if you pronounce the words "user education" you're almost certainly doing something<br>shitty. If I have 5-10 instances of gedit or Firefox (yes, I sometimes do!), all<br>with various files / objects / websites loaded, with various states (some of which<br>not serialisable, e.g. the undo history in gedit or the content of web forms in<br>websites), I don't wanna have to close them all, then change my settings, then<br>reopen them. It takes a crapload of time to do that, and it's error prone. If I<br>forget to close one instance, I might lose the setting change. Worse yet, I might<br>not be aware of that, leading to garden-path interaction breakdowns<br>(<a href="http://methodenpool.uni-koeln.de/situierteslernen/PD%20of%20HCI%20-%20Suchman.htm">http://methodenpool.uni-koeln.de/situierteslernen/PD%20of%20HCI%20-%20Suchman.htm</a>)<br>which might cost me later, when the app behaves in an unexpected way. Imagine for<br>instance that I enabled the setting to warn me when I close an unsaved file/project,<br>because the keyboard shortcut for closing all current projects is stupidly easy<br>to hit in daily use (Firefox's Ctrl+Q next to Ctrl+W for instance). I was working<br>on some project for an hour and accidentally hit the bad keyboard shortcut. I've<br>lost my work and me resolving the situation after the fact does not repair the<br>cost of the breakdown. There are good reasons why a setting must be immediately<br>applied, or why I must be VERY RELIABLY assisted in whatever procedure must be<br>followed for it to be applied. You need to tell people they have to restart the<br>app, and make sure that they can do so without mistake, and without loss of current<br>work. I doubt all individual desktop developers will do this properly, as opposed<br>to just using the damn Xfconf API and making the problem disappear most of the time.<br><br><br><br><br><br>> Lots of stuff can be programmed around, but its not worth the<br>> cost of violating KISS (this is where the care bit comes in, presumably<br>> most programmers that actually take the time to do this work don't care<br>> enough about the bloat - 'its normal' - and therefore perpetuate this).<br><br>This is not bloat at all, that's the whole point. If you implement half a correct<br>settings infrastructure in your app, it'll be as complex as Xfconf is.<br><br><br>> And you shouldn't have to put up with that situation being a possibility<br>> at all. From my perspective, blaming it on yourself is overlooking the<br>> absurd overthetopness of the situation. This is a big part of the bloat<br>> badness - having to be a superstar programmer, having to know everything<br>> from all over the place inorder to fix/implement a simple thing.<br><br>The "superstar" programmer who uses Xfconf needs to write a few dozen lines of<br>code in order to manage their settings. The programmer who does it all by<br>themselves using their "not-superstar" knowledge of UNIX will write hundreds<br>and hundreds of lines of low-level code, and have tons more error checking to<br>do. From my experience, and from evidence found by software engineering<br>researchers, it's easier to write a few dozens high-level lines with a really<br>basic APIs than hundreds of lines of system code. If the API is good, that is.<br><br><br>> It just sounds like feature bloat - implementing stuff without a serious<br>> need, and discounting the difficulty/downsides of implementing it when<br>> 'justifying' the feature.<br><br>The bloat is when you have complexity written 50 times by 50 different developers,<br>each of which tested in the wild by a single app, rather than something written<br>1 time by 1 developer, used 50 times by 50 different developers who therefore<br>test it in 50 different ways. Don't implement custom code for settings if you<br>can avoid. Xfconf is the least verbose option available to Xfce developers, ergo<br>use Xfconf.<br><br><br>> Yeah I lack a word to encompass the 'badness' involved. The 'software<br>> ethics' stuff from the FSF comes closest to the idea. A recognition that<br>> a lot of stuff used is overthetop/inappropriate/'bad', and by<br>> perpetuating it, it takes its toll on resource use, control over the<br>> code, ability to understand the code used etc.<br><br>Xfconf is opensource. All the stuff it uses is opensource. It's better implemented<br>than what all joint Desktop app developers can come up with overall if they all<br>do their crap in their corner. It's more consistent. It requires less code loading<br>overall as it's a shared library. It simplifies code and reduces bugs. Anyone can<br>see what it does, how it does it, and fork it if we decide to become evil and<br>change Xfconf to spy on users or cause cancer or whatever. Xfconf is not Mono.<br>It's not a STD. It's just good software architecture.<br><br><br>Now. I don't care if it's Xfconf or GSettings or Dconf or the new conf system that<br>a bored software engineer wrote in between two sessions of making Internet memes<br>about goats. As long as there's a single one, that is consistent and provides *all*<br>the features that are required for optimal usability, performance and <br>manageability. So let's choose one and bury the rest please. The whole "FOSS is<br>free therefore I refuse to compromise" attitude is nefarious to any FOSS community<br>in the long run. I hate GTK+ but I'm happy to read and write GTK+ code for Xfce,<br>time provided. Because it helps the community if I suck it up. I believe the same<br>should apply for settings handling, error reporting, UI design patterns and so on.<br></div>