Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
| These things are best done with the GUI (that's its purpose). The file was not | designed with hand-editing in mind. This is, of course, a nonsequitur. If A is better than B at a job, the fact that B was designed to do the job isn't really relevant. A is still better. It might be worth pointing out that, back in the 70's, one of the things that made unix so successful despite its lack of much commercial support was all the problems with fancy interactive config software on all of the commercial time-sharing systems. This meant that for every application, you had to master a separate tool to do the configuring. It was a nightmare. The guys at Bell Labs came up with this radical idea: You put the config data into a plain-text file, and include documentation in the form of comments in that file. Then the only config tool you needed was an editor, and it didn't matter which one. This is still true, and the advent of fancy graphical interfaces really hasn't changed the situation. One of the very real advantages of the apache server, for example, is that it has a relatively simple plain-text config file, which includes a lot of documentation in the form of # comments. I've worked on several projects where we first tried getting fancier web servers to work via a GUI tool, but we gave up in frustration. What usually happened then was that we would make some mistake that would turn the server into a zombie, and since the config tool used HTTP to do the configging, the config tool was also unusable. I would then download the latest apache, and after 15-20 minutes of compiling and going over the httpd.conf file, we had a functioning server. Also, it's very rare that the interactive config tools include all the config options. This is because the developers don't use such a tool much, since it doesn't work well in their semi-functional development situation. If KDE really can't be configured by editing its config files, that is a serious argument against it. What do you do when you bollix up the configuration, and as a result, the GUI config tool is a zombie? | I would highly recommend not editing this | file by hand. If you intend to deploy these key binding to a large number of | workstations, configure using the GUI and copy the necessary file, which is | ~/.kde/share/config/kdeglobals. | | That being said, the file is ~/.kde/share/config/kdeglobals, so go nuts. It would be interesting to know how reasonable it is to do this. Also, on this workstation, I don't seem to have such a file, although the ~/.kde/share/config/ is populated. Maybe it's using a default file somewhere that I don't know about?
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |