[kde-linux] Alt-F1 shortcut (Kicker) disappears
1i5t5.duncan at cox.net
Sat Apr 17 15:21:59 UTC 2010
Bruce Miller posted on Sat, 17 Apr 2010 05:57:10 -0700 as excerpted:
> I have an recurrent problem with KDE 4.x in which the Alt-F1 shortcut
> ceases to function. The Alt-F1 shortcut brings up Kicker and the panel
> (what, in another OS's terms, is called the "Start Menu").
> Does anyone know what might be causing this problem? I suspect it might
> be a "finger fumble" on my part. By definition, "finger fumbles" are
> random and therefore hard to avoid, but there is some possible comfort
> in knowing the cause.
> More importantly, does anyone know a fix or a possible workaround? So
> far, the only thing that has worked for me is the "nuclear option,"
> which is surely overkill. By "nuclear option," I mean backing up the
> ~/.kde tree and reconfiguring KDE from scratch.
> I use Kubuntu and am currently on Lucid Lynx 10.04 Beta2, using KDE
I don't know if kubuntu customizes this or not. The below describes what
There's a couple ways to set that. One is using kcontrol (aka system
settings, even tho it's kde control more than system settings), computer
administration, keyboard and mouse, global keyboard shortcuts. Select
plasma-workspace from the drop-down list. Activate Application Launcher
However, depending on your plasmoid/widget layout (number of panels and
activities, the plasmoids on each), you may have several such items
listed. You can click on each one to see what the default reference is
(if it's unset or set to something else), and set it to that, or select a
The other way to set it is more direct, and better, if you have several
launchers on various activities and panels, as this way you know which one
you're actually setting. Context-click on the plasmoid in question.
Select application launcher settings, then in the resulting dialog, the
keyboard shortcut tab. Click the button and set what you want.
As far as your "nuclear option", consider using the bisect method the next
time you are forced to "go nuclear". You didn't mention it, but this
should normally be done while working in other than kde, so from the
command line or from gnome or something, not inside kde. Backup (copy)
the ~/.kde tree as you mentioned, then in the working version (not the
backup), delete roughly half the stuff.
Start kde and see if the problem's still there or is gone. (Of course, a
lot of your other customizations may be gone, but don't worry about that,
you're just testing.) If the problem was in the part that you deleted,
the problem should be gone. If the problem was in the part that you kept,
it should still be there. Quit kde again, and delete the working ~/.kde
copy, since the test will have likely recreated a bunch of files with
default entries again, and you still have your complete backup.
Now, based on whether the problem was gone or not, copy back from your
backup the half of the settings that you now know do NOT have the problem
(the half you deleted if the problem was still there, the half you kept if
the problem was gone. Also copy back about half of the "bad" half, so you
now have roughly 3/4 of your settings, the half you know was NOT the
problem, and half of the half you know WAS the problem.
Repeat the process recursively, each time narrowing down the bad
candidates, half the first time, a quarter the second, an eighth the
Eventually, you'll know what directory the problem is in, so you can keep
everything else, and repeat the process in that directory, until you find
the subdirectory it's in, then the individual file.
When you get down to the individual file, you have a choice. (Well,
actually, you have this choice anywhere along the line, but when you get
to the individual file is where it starts getting interesting.) By this
time, based on name and narrowing missing functionality, you should have
figured out to a reasonable degree how many remaining settings that file
contains. You can confirm your guess by seeing how big the file is and/or
by taking a look at it in a text editor. If you're comfortable with
resetting any still affected settings, you can simply delete the file and
do the reconfiguring necessary.
People that don't customize that much will probably find their quitting
point earlier in the bisect, since they don't have many customized
settings lost that they have to reconfigure. Heavy customizers such as
myself will continue the bisect far further, since they have more to lose
at the same point in the process. Others may simply be curious, and want
to find what went wrong to the finest degree possible. I'm generally one
of those folks too, even where I don't customize so much.
If you aren't satisfied with just the file, you can continue the process
into the file itself, using the text editor instead of file operations,
now. KDE has deliberately continued to keep nearly all settings in text
based files, precisely so they /can/ be edited with a simple text editor,
if need be.
Often, you'll find the file is the reasonably standard *.ini file format
that was popular back in the MS Windows 3.x days. These have sections
denoted by [titles], followed by lines of configuration for that section,
usually in setting=value format. These files are very easy to continue
bisecting. Simply choose about half the file to delete, working with
whole sections. Continue bisecting until you find the specific problem
When you know the specific bad section in the file, you again have the
choice of simply deleting that and reconfiguring what's left, or focusing
now on just the bad section and continuing the bisect to the individual
line level, the individual configuration item.
Now some general bisect method observations, based on experience. The
first few times you do it, it'll be hard. But as you get more familiar
with the process and the way each app or family of apps (all of kde in
this case) stores its settings, it'll get much, much easier, as you'll
already have an idea where the problem is before you start, often to the
file or just a few files level, thereby eliminating multiple bisect
iterations before you even start.
With kde, the settings tend to be in one of two subdirs, both under
~/.kde/share. Kde apps with just a few settings, a file or two worth,
generally keep them in ~/.kde/share/config/ . Kde apps with more settings
or data and settings, enough to have a subdir of files, will use a subdir
in ~/.kde/share/apps/ instead.
So your problem is very likely to be in either an appropriately named
file in ~/.kde/share/config/ , or in an appropriately named subdir in
~/.kde/share/apps/ . Knowing just that already eliminates a bisect
iteration or two, and if you can either guess what subdir/file by looking,
or at least eliminate half or more that you know definitely do NOT apply
so you don't need to test them, you eliminate even more bisect iterations,
and with a bit of experience, you'll often need just one test at the file
level to confirm your guess, before diving into the file itself, should
you decide to do so.
One important exception to remember is that some of the newer apps and
settings are in the freedesktop.org standard config or data dirs. Akonadi
settings are one example. ~/.config/ (or other similar location set
either by your distribution, or the $XDG_CONFIG_HOME and $XDG_DATA_HOME
variables, if appropriately set and exported, thus giving the user a way
to change the location, if desired) is used for these, instead of
~/.kde/. But this is pretty easy to figure out, if the problem doesn't go
away when you backup and remove the entire ~/.kde dir, and now you have a
pointer as to where to look next. =:^)
Another option, tho it requires a bit more skill then bisect, and that you
know what specific application is the problem (thus, it wouldn't work
here, since you're not sure what's causing the problem, only that it
occurs over time), is to use strace, and then grep, running from a konsole
window. This works great if you want to know where a specific app looks
for its config, for instance, or if one is crashing, so you know where to
start your bisect as above. You can check the strace and grep manpages
for details on the options.
strace -f -eopen <app> <app options and parameters>
... will give you a list of all the files <app> tries to open as it runs.
The problem with just strace is that for the average modern X based app,
especially kde and gnome apps, you'll often have output of several hundred
if not several thousand lines to go thru (several times that if you were
tracing everything, not just file opens). One thing's for sure, an strace
like that really DOES give you an appreciation of just how much work your
computer is doing behind the scenes!
But to filter that output down a bit, you pipe the output to grep, like so:
strace -f -eopen <app and parameters> 2>&1 | grep <path you're interested
in> | grep -v <stuff you're not interested in>
The 2>&1 bit is important, as strace's output normally appears on STDERR,
not STDOUT, so it won't get piped to grep unless you redirect STDERR (file
descriptor 2) to STDOUT (file descriptor 1).
As a more real example, try this (replace /home/user as appropriate):
strace -f -eopen systemsettings 2>&1 | grep /home/user/
As that's still a lot of output, we'll start by filtering out references
to icons and cursors with a second grep:
strace -f -eopen systemsettings 2>&1 | grep /home/user/ | \
grep -v 'icon\|cursor'
The \ ending a line simply tells the shell to continue with the next line,
treating them as one. The -v tells grep to filter these out. As you'll
note, I used quotes on the second grep's search term, so the shell
wouldn't try to parse the pipe (|) and redirect to a command called
"cursor". The | means "or" in regular expression language which is what
grep uses, but it has to be escaped by the \, or it would simply be taken
as a literal | symbol. So the second grep says filter out lines that
include "icon" OR "cursor".
Here, for a simple systemsettings run without actually changing anything,
that's actually getting almost manageable, "only" about 60 lines of output
to sort thru. But as soon as you actually start wandering around in
systemsettings, you'll get more output again. You could take a look, and
say, OK, I'm not interested in fonts either, and add that to your grep -v
line, with the appropriate \|, and continue filtering out additional stuff
until you get something manageable. A hint, "ENOENT" means the file or
directory doesn't exist, so if you're only interested in files that exist,
you can add that to your grep -v filter. And if you're only interested in
files in ~/.kde, you can add the subdir to the first grep. You will also
probably see references to your style config, (oxygenrc, here), that you
can filter out, along with fonts/cursors/icons, but I didn't add here, as
if you use a something other than oxygen, that might have confused you.
I'm sure that's WAYYY more info than you expected, but perhaps it'll be
useful, if not to you, maybe to someone else who ends up reading it. =:^)
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
More information about the kde-linux