On Wednesday 22 April 2009 10:27:29 Michael Schuerig wrote: > On Wednesday 22 April 2009, Joseph Rawson wrote: > > Before setting kwin to handle those > > settings, I tried to set those values in konsolerc, and I put the > > [$i] option on them. This seems to work, but to do this, you have to > > logout entirely and edit the konsolerc file in a terminal, then log > > back into the desktop. I think that this is probably the better way > > to configure this, as it doesn't rely on kwin. > > Could you explain a bit more detailed what you're doing? What's the > purpose of [$i]? Does it make a setting immutable? Where is it applied? > Certainly! :) The information was obtained here: http://techbase.kde.org/KDE_System_Administration/Configuration_Files#Lock_Down The [$i] appended after either an option or section makes either the option or setting immutable. This is most commonly used in the /etc/kde3 files as a way to lock down the system configuration. Different applications treat this option differently, but every application that uses a KConfig object will not be able to write a different setting . An application may not honor those settings while it's running, as with kdesktop, you can change the number and name of the desktops, but on the next login, you'll still get the preset number and names for the desktops. While you're at it, you may also be interested in the [$e] setting, as you can use environment variables in your configuration options. This helps make the configuration more portable. I learned this when I was tasked with sharing my configuration with other people. My home directory is in /freespace/home/umeboshi , but most people use /home, and the use of [$e] helped a lot here. When I was new to using linux, I used to just make the largest partition /home, but after a while, I found that to be limiting, as I had network shares, and backup directories that weren't appropriate to place in /home, so I just started calling the partition /freespace and placing home under there. BTW, this also helped me determine which applications were using a hardcoded /home/$USER in their code, instead of using $HOME. I rarely see this type of problem anymore, but I've found the moving stuff outside of their traditional directories is a quick and easy way to notice problems that shouldn't be there, but that most users never experience. > Michael > > -- > Michael Schuerig > mailto:michael@schuerig.de > http://www.schuerig.de/michael/ -- Thanks: Joseph Rawson
Attachment:
signature.asc
Description: This is a digitally signed message part.