Setting Panel to Hide Automatically in fractions of a second (kde 3.5.10, Debian 5.0)
1i5t5.duncan at cox.net
Thu Feb 25 18:14:58 GMT 2010
Randy Kramer posted on Thu, 25 Feb 2010 10:22:41 -0500 as excerpted:
> If this is not an appropriate mail list for this question, maybe someone
> can direct me to a more appropriate mail list.
> The short request: I'd like to find a way to set the Panel to Hide
> Automatically in fractions of a second--the GUI setting under kcontrol
> only allows increments of one second. I'm assuming that there is a
> configuration file and setting that I can use to set the delay in
> fractions of a second.
> Background: I'm trying to better train my mouse hand ;-), but the
> choices of "Immediately" and 1 second don't work for me--1 second is too
> long to wait, and if I have it set for Immediately, it seems that the
> slight mouse movements I (accidentally) make when trying to pick out the
> right icon to click on (e.g., to select a desktop) let the Panel
> disappear before I've selected what I want.
> I'd like to experiment with settings around 1 tenth of a second (i.e.,
> 100 milliseconds or so).
> I've tried googling and doing an ack-grep for things like panel,
> autohiding, etc. in my ~/.kde directory--I need a hint (or more).
Interesting question. The kind I might find myself asking. =:^)
Most of us regulars here are going to be on kde4 by now, so won't likely
be able to help with specifics, but I'll give you some general hints,
based on my approach in such circumstances. =:^)
First, based on my experience with the below, I narrow down the search
domain for you, which will come in useful, below. In general, both kde3
and kde4 keep nearly all of their user settings under $KDEHOME, which is
~/.kde by default (if that var isn't set in the environment), tho
distributions commonly patch that to a version specific location (~/.kde3
or ~/.kde3.5 or similar). So I'll just use the default ~/.kde from here
on, you can make the substitution as necessary. (There's one exception,
Within that dir, nearly all settings are in two subdirs of the share
subdir, apps and config. So the two dirs we're interested in are
~/.kde/share/apps and ~/.kde/share/config. If you check them, you'll
quickly see that config contains individual application specific config
files, while apps contains application specific subdirs of its own.
Generally speaking, kde apps needing more than a single config file or two
create a subdir under apps and store their config there, while those for
which a single file or two is enough, store their config in the config
subdir. But it's these two dirs you're interested in.
Now, what to do when you need to find where an app is storing its config?
Well, I use a handy command line app called strace. This hooks onto an
app and reports information about the system calls it makes. The idea is
to strace the application we normally run to change the config, while we
change it, to see what it's doing. Here, we're only interested in file
access so we can see where it's storing its config, so we'll limit
reporting to that. Further, since that's still pages and pages of output
for a typical kde app (which after all checks several places by default
for many of its libraries, opens all sorts of icons, font files, etc, and
in general, does far more in far less time than you'd ever dream possible,
if you weren't familiar with how it worked -- playing around with strace
can be VERY enlightening, in that regard, giving one an entirely new
appreciation for what your computer does behind the scenes just to startup
a single app!), we'll limit our file access reporting to file open
To do that, we'll use strace like this (from a konsole window, so you get
strace -f -eopen <application and its command line parameters, if any>
The -eopen limits the output to file open requests (-efile would be all
file access activity, opens, stats, reads, writes, seeks, closes...); the
-f says trace process forks as well. Application is of course the app
you're tracing. Here, it'd be whatever you run to set the panel delay.
But if you try that you'll see just what I was talking about in terms of
all sorts of file accesses you wouldn't have even guessed at; WAY more
than you can easily process. So we'll filter the output down a bit
further, by piping the output to grep. It's all one command line, tho I've
wrapped it here for posting.
strace -f -eopen <application and parameters> 2>&1 |
Replace the $HOME and .kde as appropriate for your system, of course. The
2>&1 redirects STDERR to STDOUT, as the strace output appears on STDERR,
and the pipe is piping STDOUT to grep's STDIN. If the STD* stuff doesn't
make sense to you, just read it as saying we're connecting things up so
grep gets the stuff we're trying to filter.
The results should be far fewer now, actually getting to be something
almost manageable. If the results are still too many, you can filter them
down further, using grep -v, the -v meaning only print anything NOT
containing the search term (thus the reverse form of grep). This example
is from kde4 as that's what I'm running, but it should demonstrate what I
mean, repeatedly filtering several additional terms out of the output, to
make it more manageable.
strace -f -eopen <application and parameters> 2>&1 |
grep $HOME/.kde/share/ | grep -v oxygenrc | grep -v khtmlrc |
grep -v colors
Of course, this only works if you run a new application to change the
config. If you want to trace an application already running, you need its
PID (process ID), and can then tell strace to attach that pid. Use top,
ps, pidof, ksysguard, or your favorite process listing app to get the pid,
then feed it to strace using the -p <pid> option. See the strace manpage
(and those for top, ps, pid, etc) for more.
I've found many a config file in my time using this technique, which I
used first on MSWormOS using the excellent sysinternals tools, back before
I gained my software freedom. With freedomware, if you understand source
code, you can of course go check it to see what config file it uses, but
tracing the file opens is a method that doesn't require the source or
knowing how to read it, only a few tools and a bit of knowledge in how to
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.
More information about the kde