Setting Panel to Hide Automatically in fractions of a second (kde 3.5.10, Debian 5.0)

[Duncan]

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, 
~/.kdeglobals.)

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 
requests.

To do that, we'll use strace like this (from a konsole window, so you get 
the output):

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 |
grep $HOME/.kde/share/

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 
use them.

-- 
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.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.