Boston Linux & Unix (BLU) 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

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

key bindings



| 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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org