User: Password:
|
|
Subscribe / Log in / New account

The case for the /usr merge

The case for the /usr merge

Posted Jan 28, 2012 14:44 UTC (Sat) by Los__D (guest, #15263)
In reply to: The case for the /usr merge by nix
Parent article: The case for the /usr merge

> gconf: well, OK, I'm a KDE man and prefer the ini-files-and-ksycoca thing. gconf *is* horrible and has no right to exist: there are better ways to provide performance as good as binary deserialization without needing all your configuration to spend all its time living in a binary lump.

Errrr, GConf is not using a binary lump... It is using directories and XML files.


(Log in to post comments)

The case for the /usr merge

Posted Jan 28, 2012 15:02 UTC (Sat) by nix (subscriber, #2304) [Link]

I thought it could use both, but preferred binary lumps?

... oh, hang on, that's *d*conf, isn't it, where the d stands for 'a letter earlier than g in the alphabet' or something like that. I always get them mixed up.

gconf

Posted Jan 29, 2012 0:22 UTC (Sun) by Richard_J_Neill (subscriber, #23093) [Link]

..in fact, gconf really is excellent. It:
- Has an underlying XML filestructure, which is possible to manually edit (though not so good as the .ini format), and these files can be copied around like other dotfiles.
- Has a CLI interface, gconftool-2, which lets you get and set certain keys. This is REALLY(*) useful.
- Can support changing settings in real-time (across multiple instances of the app without restarting the app, and even without needing an "Apply" button).
- Has a GUI editor: gconf-editor, which is useful for finding the keys whose name you don't know.

(*)For example, I've set up a new system. I want to preserve most of the system defaults, and especially if there is a new feature I don't know about, I don't want to remove it from the conf-file. But there are about 20 settings I really want to keep. So I have a script with lots of lines such as:
gconftool -t string -s /apps/metacity/general/button_layout 'menu:minimize,maximize,close'
I can run these commands inside a running GNOME session, and they immediately take effect.

[Sadly, KDE doesn't have such a system, as far as I can tell. It's impossible to script the setup of a KDE system in a non-brittle way]

gconf

Posted Jan 29, 2012 11:38 UTC (Sun) by k8to (subscriber, #15413) [Link]

You lost me at "excellent ... XML".

gconf

Posted Jan 29, 2012 22:49 UTC (Sun) by Los__D (guest, #15263) [Link]

I was just waiting for an ridiculous comment about XML... A there it was.

gconf

Posted Jan 29, 2012 23:09 UTC (Sun) by k8to (subscriber, #15413) [Link]

That was actually a pretty reasonable one. I could make a ridiculous one if you want.

gconf

Posted Jan 29, 2012 15:27 UTC (Sun) by HelloWorld (guest, #56129) [Link]

> [Sadly, KDE doesn't have such a system, as far as I can tell. It's impossible to script the setup of a KDE system in a non-brittle way]
KDE does have tools for that purpose. Check out kwriteconfig/kreadconfig. It doesn't work as well gconf though. Changes aren't applied immediately, and there's no GUI editor I'm aware of.

gconf

Posted Jan 29, 2012 15:41 UTC (Sun) by Richard_J_Neill (subscriber, #23093) [Link]

I know of kreadconfig/kwriteconfig. Unfortunately, it doesn't work at all well - you have to already know which file the setting is in, and details of the setting name and the ini-file grouping. kread/writeconfig are simply a friendlier equivalent of 'sed' that speaks the .ini format.

The way this should work (and I filed a bug on this years ago) is that kcontrol ought to expose every single field in the GUI via DCOP. Then it would be easy to find out what keys to use. At least a way to recursively dump all the kreadconfig keys would be nice...

gconf

Posted Jan 30, 2012 2:34 UTC (Mon) by HelloWorld (guest, #56129) [Link]

Huh? You can explore the configuration simply by looking at ~/.kde/share/config, so why do you need kreadconfig to dump all keys?

gconf

Posted Jan 30, 2012 2:44 UTC (Mon) by Richard_J_Neill (subscriber, #23093) [Link]

Well, it can be rather tricky to find out which conf-file does what, if you don't already know. If you don't know the key-name, section-name, or possible values, it's not easily discoverable.

BTW, In gnome, the easiest way to derive the changes is this:

1. Start with a clean distro installation.
2. Dump all the gconf keys.
3. Change lots of things to taste, within the GUI.
4. Dump all the gconf keys.
5. Use diff to discover the changes, and generate a script that will make these changes the next time.

gconf

Posted Jan 30, 2012 3:32 UTC (Mon) by HelloWorld (guest, #56129) [Link]

I still don't get it. What stops you from doing just the same with .kde/share/config? diff -r is your friend.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds