<div dir="ltr">Woops, missing the first part of the novel I just wrote. This reads *before* the previous email :D <br><br>Needless to say, don't take this email entirely to the first degree. I'm ranting<br>like the moron I am, with no political correctness filter, about this specific<br>topic but it should be stated I'm not targeting anyone in particular and this<br>conversation can be had about pretty much every other type of software we're using<br>and developing at Xfce.<br><br>> 'user tools and demands' - is there a demand for such integrated and<br>> extravagant settings maintenance though? (I know Matthew has responded a<br>> little later, will respond to that too). Are these demands from<br>> 'enterprise', which seems to be like a bloat cancer to anything it<br>> touches (e.g. its no longer a libre desktop under the control of the<br>> user, it is part of a larger system of control by sysadmins that want to<br>> have integrated settings, immediate updates, control over users and what<br>> they can set, etc etc)?<br><br>Yes, there is demand for having configuration files that are located at<br>predictable locations, and an interface that will look for said files in <br>a predictable order. There is also demand for whatever entity manages<br>this interface to automatically detect changes. For two reasons:<br><br>1. Yes, multiple apps share the same config item. Even though, often, there<br>will be one or few writers, there may be multiple readers for a setting. For<br>instance, multiple apps may want to know the user's locale, favourite font,<br>desktop resolution, wallpaper, GTK+ theme, a11y preferences, printer preferences,<br>and so on. Considering only panel plugins, an app may have a good rationale for<br>reading Power Manager settings (are we in power saving mode, or can I waste CPU),<br>sound settings (e.g. some language training app or video chat app that checks if<br>the volume is muted / very low in case the user doesn't respond to audio stimuli),<br>clock / time, workspace names / switching behaviour / etc. Most plugins directly<br>interface with or extend existing settings because those are relevant to Desktop<br>UX and to Desktop apps.<br>2. Sharing / syncing configuration across multiple workstations, automatically<br>updating configuration in an enterprise environment. I can't take seriously the<br>idea that we don't want to support basic enterprise needs because it "removes"<br>freedom from users. If someone is unhappy about having to obey social norms in<br>any kind of group institutions, they might as well go live as an ermit. As DE<br>developers it's not our place to discuss enterprise security / workstation<br>management policies, but to allow all the involved stakeholders to implement<br>whatever policies and configurations they need. As someone working in usable<br>security I can tell that most prohibitive enterprise policies are counter-productive<br>and stupid, but I still need to let sysadmins deploy default config files and<br>updates in a reliable way. There's also the case of PoS public devices where the<br>session *must* be locked-down because all users are unauthenticated and untrusted.<br><br>So yes, being able to accurately locate where the configuration file for an app is<br>is necessary.<br><br><br><br>> There isn't a maintenance burden here, since I'm around, and if there<br>> was and I wasn't then you move to the question of whether it should be<br>> part of the official XFCE4 codebase (but thats a long way in the future...).<br>> <br>> I'm not part of the team, so I can choose freely here.<br><br>I was making a more general comment. I personally prefer Qt over GTK+ but I don't<br>write my Xfce code in Qt because it makes it easier for the rest of the Xfce<br>community to reuse it if I do the same as others.<br><br><br><br>> Yeah, I understand the idea of a central settings object, not objecting<br>> to that (just XML, anything dbus, having a superfluous always-running<br>> daemon just for configuration, etc etc).<br><br>You're reading "KISS" as "prefer the smaller / least feature-rich API". If we<br>reasoned like this we might say as distributors that Awesome is KISSer than Xfwm<br>and nano/vi KISSer than Mousepad. The whole point of Desktop Linux existing is that<br>sometimes the additional "bloat" (aka basic usability features) makes our lives<br>better. You're saying that you have an ethical consideration in not using "bloat",<br>and by doing this you are reducing the utility of said "bloat" and ruining the user<br>experience.<br><br>Let's consider two interfaces: the ultimate KISS iface and Xfconf. The 'you' used<br>below applies to any Desktop developer including me, not you specifically.<br><br>With the KISS iface:<br>- you read a file with open/read/close<br>- you need to guess where to load the config from, manually<br>- you parse it yourself with your own code embedded in your own software<br>- you manually poll for changes, and manually integrate your polling logic with<br>  your existing UI event loop<br>- you manually bind UI properties to your file using custom code<br>- bindings are not atomic: either you reload the whole config or you write<br>  additional code to detect which properties changed and only update those<br>- you manually save your file when you change a property, and you need to handle<br>  permissions and changes to standard XDG dirs in order to save them in the right<br>  location<br><br>With Xfconf:<br>- you don't need to do file-parsing<br>- your config is always loaded from the best location, without you needing to<br>  write manual code<br>- you have a strongly typed, foolproof API for reading and writing settings<br>- your change polling directly integrates in your UI's existing and mandatory<br>  event loop<br>- you have one-line functions to bind UI properties to settings<br>- your bindings are atomic: Xfconf will only update you on the single property<br>  that changed<br>- you no longer need to save config files, it's done automatically and at the<br>  correct location no matter what<br><br>Key fact of software engineering: every developer, no matter how cool they think<br>they are, introduces a constant amount of bugs per line of code written. Let's<br>be generous (so that pedants don't whine at the number) and say it's between 5 and<br>50 bugs per 1000 LoC. It doesn't matter. Less code = less bugs. Period. The constant<br>holds relatively well regardless of language and code complexity, too.<br><br>Corollary: the less live code your system has, the less bugs your system has.<br><br>Corollary: factorise code as much as you can. Less code on the system means the<br>system has been kept simpler overall. Code duplication is way, way worse than<br>code complexity.<br><br>Key fact of software engineering: the more diversely you test and use code, the<br>more you detect bugs. Complete coverage of an API implies verifying that it behaves<br>properly for all possible input ("proving" it works as expected). This happens more<br>if the API is used by 20 different projects than by one project.<br><br>Corollary: reimplementing the same thing as your neighbour is really, really stupid.<br>It leads to either everyone doing their own stuff and no standard existing, aka no <br>predictable way existing for third-party hackers to hack how their apps run, or it<br>leads to people just doing the same thing and apps having to be individually updated<br>every time the standard evolves.<br><br>Corollary: every time two app developers have a common need, they should implement<br>that in a shared library rather than shipping their custom code.<br><br>As long as app developers don't respect a strict cross-desktop standard for config<br>files (among other things), we'll never have efficient and robust implementations of<br>features such as sandboxed desktop sessions or migrating live apps across<br>workstations. These things might not matter to you as an individual developer but<br>they do to other developers and to some users. And these complex features, ironically<br>are available only if every follows standards to the letter.<br><br>If this argument doesn't convince you of the KISSness and superiority of consistency<br>over personal developer ethics in a desktop, consider the case of fonts and themes.<br>I don't like the way GTK+ works, ergo I will have my own way of parsing theme files<br>and applying themes. And I will have my own way of having the user select a font for<br>my system. Now, users with a11y issues need to go through the painful process of <br>navigating through an interface that has a default theme with a font too small, or<br>with too little contrast, for each and every of their apps instead of doing it a<br>single time. And OEMs who want to ship distros that just work by default for such<br>user bases need to repackage all the apps with all their custom configuration files<br>because the developers are selfish, instead of having to change a single theme<br>file / package.<br><br>Let's go back to KISS vs Xfconf. Surely the Xfconf features are unnecessary?<br><br>Automatic config location resolution: allows for system-wide implementations of<br>multiple sessions or app profiles. Allows for multiple stakeholders overwriting<br>config in a predictable order, regardless of the app's internal logic. Allows for<br>users to easily, reliably migrate their configuration. By default. Without the <br>automatic location resolution afforded by config librations like Xfconf, we rely<br>on developers not being assholes and being up to date with standards in order to<br>obtain reliable user experience. A quick "ls -la" will show you how many assholes<br>there are out there in the wild who don't put their config files in the XDG<br>directory for user config files. I personally have software from 50-100 different<br>assholes (none of them Xfce <3). I stopped counting halfway through.<br><br>No manual file parsing: since you're ok with GKeyFile I'll assume we agree that<br>not letting hundreds of individual devs play with fopen or open APIs is a good<br>idea. From having supervised the programming of dozens of CS students, I can<br>guarantee you that you don't want to let most developers out in the wild do<br>something as basic as reading and parsing a simple RC or XML file.<br><br>XML vs binary vs RC: I prefer RC. XML has its own advantages since it removes<br>potential ambiguity and limits the risk of those who refuse to use the standardised<br>API and want to manually edit their config not escaping characters properly when<br>dealing with complex config data. For instance if I named my workspace "Work [email]"<br>and forgot to escape the brackets, how would a RC file parser react? Would XfceRC<br>and GKeyFile behave the same way? Answer: NO. XfceRC and GKeyFile write and read<br>string lists with a different syntax! They CANNOT be used interchangeably for the<br>same config file! One of them will end lists with a semi-colon and the other will<br>interpret this as the list ending with an empty element.<br><br>WHICH BRINGS ME TO THIS DESPERATE CRY: CAN WE PLEASE BURN XFCERC TO THE GROUND AND<br>USE GKEYFILE LIKE RESPONSIBLE SOFTWARE DEVELOPERS!? Thanks *insert your favourite<br>emojis here for added dramatic effect*<br><br>This kind of absolutely stupid situation is avoided by forcing everyone to use the<br>same API and not allowing them to decide how that API parses and writes files.<br><br>But I don't want a stupid daemon, I can poll the file myself: you hypocrite. When<br>you do file polling, what you do is using a daemon called the Linux kernel and an<br>API called the Linux IO system call interface. Software engineering fact: reading<br>from IO is slower than reading from memory. The kernel has no standard polling<br>interface because whether such interfaces could work depends on the underlying<br>filesystem. This means you have no guarantee, when using polling iface Foo or Bar,<br>and when you have 10 instances of your program running, that it will efficiently<br>avoid duplicate effort. In fact, I'm willing to bet that most polling ifaces will<br>require some thread regularly poking the file for changes and that at least<br>sometimes, the fact that the file has changed will not be cached and you will<br>do more reads on the filesystem than strictly necessary. A daemon that takes upon<br>itself to cache the config eliminates this problem. Changes to the file require<br>a single act of polling, opening and reading and changes to the config from one<br>of the daemon's clients requires no reloading of the file at all. Writes occur<br>from a single process and so if multiple changes occur consecutively, the kernel<br>will do a single actual write to the filesystem whenever the filesystem type allows<br>that. You no longer need all competing config APIs / desktop devs with their manual<br>code to drop the "O_DIRECT" flag on the config file to obtain performance. And, is<br>your polling strategy optimal? How often does your polling library check the file<br>for changes? How well does this integrate with your UI event loop? What is the<br>upkeep of you polling your file (AND ALL OTHER POTENTIAL LOCATIONS FOR THE CONFIG<br>FILE, see point above about locations) in 10 instances as opposed to your 10<br>processes receiving a single signal/message when a single daemon polls the file /<br>transparently sends updates about settings which do not require file re-reading?<br><br>File-based settings are just as good as daemon/IPC based ones: no. When you're done<br>polling for changes and reloading the whole file in memory in each of your instances,<br>you now need more custom code (aka more bugs) to decide which settings to reload.<br>You then need to call your custom handler to update your settings UI and your actual<br>configuration. If you had instead bound your UI and configuration to a single Xfconf<br>key, all of this would have been done transparently. When you poll a file, you also<br>need to decide what the crap it means when there is a mount event on the file, when<br>it is renamed, etc, etc. Wanna bet that developers WILL make mistakes and have<br>inconsistent behaviour across apps if we let them use GFileMonitor? If you get an<br>unmount event on your configuration file on a FAT32 filesystem, what does it mean?<br>For which filesystems is the mount event not valid, and just a result of the<br>awkward/non-compliant implementation of the filesystem? Etc, etc.<br><br>But I don't like GObject: good on you. You prefer to implement your own thread,<br>your own routine logic and then integrate this with your GMainLoop (because you<br>already use GTK+)? Have fun with that.<br><br>But I don't like DBus: DBus is the de-facto standard IPC API for Linux. The reason<br>is simple: it's infinitely easier to construct strongly typed messages with DBus<br>than it is with UNIX Domain Sockets or other IPC mechanisms. In fact, DBus is<br>currently migrating to the Linux kernel. It will ultimately provide much better<br>interfaces for security integration (both SELinux / namespaces) and spawning<br>multiple sessions than UDS do. UDS are unmanageable, all you can do is translate<br>PIDs across PID namespaces and apart from that you have no security and need to<br>implement custom intermediary daemons for each app/API that relies on a UDS and<br>understand the custom semantics of the app to provide basic access control. UDS<br>are not adapted for Desktop IPC. Various process polling files is as unmanageable<br>by third-party security mechanisms as UDS or pipes or other non-standard, untyped,<br>not necessarily well authenticated communication channels.<br><br><br><br>> Yes, its a 'nice to have' to have multiple instances of an application<br>> share configuration, but it is standard practice for this not to happen<br>> (because naturally settings are saved in one configuration file that<br>> should be read at the start, and written to later etc etc). Beyond this<br>> you can lock the configuration file and tell the user that other<br>> instances should be closed before you commit any changes.<br><br>It's not just nice, it's absolutely necessary. Will discuss this point below in<br>response to your next email.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 2 May 2016 at 19:52, 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"><span class="">> 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></span>Less code = less bugs. The bugs per LoC constant.<span class=""><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></span>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...<span class=""><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></span>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" target="_blank">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.<span class=""><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></span>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.<span class=""><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></span>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.<span class=""><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></span>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.<span class=""><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></span>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>
</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>