3 ms·
Examples? Well in my case nothing is stored in Gconf: vim, irssi, apache, postfix, firefox, skype, sound settings, wifi etc So what's the point of this "standa
by old-gregg 17y ago
Examples? Well in my case nothing is stored in Gconf: vim, irssi, apache, postfix, firefox, skype, sound settings, wifi etc
So what's the point of this "standard API" then? Just to make life harder for KDE/XFCE folks to run GTK apps that were written by unfortunate souls who use gconf and suddenly packaged with gconf-daemon as a dependency?
- viraptor 17y agoI meant user apps. Servers don't need unified storage that much and they don't belong to user accounts really. Ok, so skipping server stuff (and remembering that the question is "examples of what it cannot do"): Skype is not really a part of the linux environment... they do what they want and they would probably prefer to just port the windows solution, but I don't see anything they could not store in gconf. Sound settings - gnome-volume-control uses it, same with gnome-sound-recorder, gstreamer too - sound server itself is system-wide, so it doesn't have place in gconf. Vim uses scripts, same as Irssi, so fair enough it cannot be done Firefox could use gconf - it just needs a key=value set. Apache, postfix, wifi, sound daemons - those are servers/system-wide providers... From the project site: "GConf is a system for storing application preferences. It is intended for user preferences; not configuration of something like Apache, or arbitrary data storage." But I think I lost the main point somewhere - here it is: of course you cannot do everything in gconf (scripts), but most of the app preferences fit this model perfectly - and many of them do use gconf - just check the list of apps using it on your system.
- FooBarWidget 17y agoExamples? Uh, pretty much the entire Gnome desktop? Pretty much all Gnome applications? Gedit, Nautilus, Gnome Terminal, Metacity, Compiz? Yeah so GConf isn't a standard for the entire system. So what, does it need to? GConf has never promoted itself as a system-wide standard, just as a standard for Gnome. The point? As someone else said, GConf provides change notifications, something which is an integral part of the Gnome UI experience: instant-apply for all settings. If you change a window manager hotkey in a config tool, Metacity/Compiz will immediately notice the change. If you change some Gedit setting in a different tool then Gedit will immediately pick it up. Firefox doesn't use GConf because they already have their own cross-platform config storage system, and they suffer for it: if I change the fonts (font settings are stored in GConf) then every GTK app immediately picks up the change, but not Firefox - I have to restart it. You said GConf is a reinvention of the registry, and for some reason you apply a negative label on that. None of the technical reasons on why the registry sucks, as mentioned in the article, is true for GConf: - GConf does not store settings in a big monolithic file that tries to reimplement the filesystem. It stores each config directory as a separate XML file on the regular filesystem. These XML files are parseable and editable with standard XML tools, which are plentiful. - GConf has pluggable backends. The XML one is just the default one. You can write a backend that stores settings in an SQlite database, a MySQL database, or even the Windows registry, or maybe as files in /etc if that's what you really want. - GConf is completely open. There are no weird file format glitches. The default XML files are portable between machine architectures. Basically the only reason you hate GConf is because it looks like the registry, and because the registry is bad, everything that looks like it must automatically be bad regardless of their actual design and implementation merits, right? What is this, 2002? I thought people were finally over this nonsense but apparently not.
- old-gregg 17y ago"Entire gnome desktop"? WTF is that? Everybody is using a mix of Qt/GTK apps, and thanks to "just-for-gnome" turds like gconf nothing gets along and you have to google and dance around several incompatible configuration GUIs. Pardon me, but "instant apply" feature is not enough to excuse for this mess: yeah, I change something in Gconf and maybe 20% of apps pick up my change instantly. A whopping 20%, but INSTANTLY, was that the goal? They should have ALL kept using standard /etc + ~/.xxrc files or came to an agreement to use something truly global, so I could enjoy the same font rendering or a freaking window colors in Skype and Pidgin. I can live without instant config changes but at least I could have grepped "color" and "window" appearing on the same line somewhere in /etc and in ~/.gtk or ~/.kde. Tools like GConf are destroying one of the greatest UNIX strengths: scriptability. I keep versions of config files for selected software under git and simply push it to /etc when I need to quickly set up a new machine. Nobody needs freaking "pluggable back-ends" because everybody needs to be able to instantly backup/restore selected applications configuration in a standard way And is it really worth it to run a freaking daemon so you can see your config changes instantly take effect? Also, your comment has "XML" in it. Are you sure? Seriously? Why not PDF? It's about as good as XML for storing key=value pairs, there are lots of tools developed for it too! And just as useles for sed/awk/grep. This disease of bloating up simple things into monstrosities based on "pluggable architectures" must be contagious: some infected gnome devs must have sat at the same table with GRUB-2 folks, so now we've lost a great bootloader.
- FooBarWidget 17y ago> Everybody is using a mix of Qt/GTK apps, and thanks to "just-for-gnome" turds like gconf nothing gets along and you have to google and dance around several incompatible configuration GUIs. So now we have, Gnome-specific config storage, KDE-specific config storage, and the rest all uses its own config storage. So now we have at least two classes of apps that use their own standard config storage. Getting rid of GConf would mean all of those apps would use their own config storage, creating even more fragmentation. That would be better, how? > Pardon me, but "instant apply" feature is not enough to excuse for this mess: yeah, I change something in Gconf and maybe 20% of apps pick up my change instantly. A whopping 20%, but INSTANTLY, was that the goal? No idea where you pulled the 20% number from. It's always 100% in my experience with the exception of Firefox and font settings. > They should have ALL kept using standard /etc /etc is not a standard. Did you ignore what everybody else has been saying? > + ~/.xxrc files Oh like ~/.gconf? > or came to an agreement to use something truly global, so I could enjoy the same font rendering or a freaking window colors in Skype and Pidgin. I can live without instant config changes but at least I could have grepped "color" and "window" appearing on the same line somewhere in /etc and in ~/.gtk or ~/.kde. Agreed, but this problem has got nothing to do with GConf. Getting rid of the GConf you so hate will not solve this very problem. > Tools like GConf are destroying one of the greatest UNIX strengths: scriptability. gconf-tool. Completely scriptable. Enjoy. > I keep versions of config files for selected software under git and simply push it to /etc when I need to quickly set up a new machine. Put ~/.gconf in git. Enjoy. > Nobody needs freaking "pluggable back-ends" because everybody needs to be able to instantly backup/restore selected applications configuration in a standard way Yeah, if only those stupid GConf files are backup-able with standard tools like 'cp' or 'tar'! Oh wait... they are! > And is it really worth it to run a freaking daemon so you can see your config changes instantly take effect? It is really worth requiring an entire windowing system and fancy graphics just so one can see images in a web browser? We should just stick with telnet dammit! Yes. Why not run a daemon? It eats maybe a few hundred KB of private RSS. Even an old desktop system by today's standard has 256 MB of RAM. The daemon also improves startup performance by caching a small set of active configuration settings in memory instead of having to constantly load them from disk, something which is not possible if every app parses the config files. > Why not PDF? Why PDF? I'll tell you why not PDF, because it's not a good format for storing config, what's why! You said there are lots of tools for editing PDF - but none of them are usable for editing key-value pairs. As opposed to XML tools. If the XML file hard to read? Use xmllint to reformat or to indent it. Edit with a standard text editor. grep, sed, awk, all work, I have no idea what you're talking about. No, I think your fear for 2010 technology and your tendency to stick with 1970s stuff is more of a disease.
- kelnos 17y agoYou do realise that KDE and Xfce both have their own configuration storage systems that aren't compatible with gconf, right? (Disclaimer: I wrote Xfce's current config storage system.)