[kde-linux] Alt-F1 shortcut (Kicker) disappears

[Duncan]

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

I don't know if kubuntu customizes this or not.  The below describes what 
kde ships.

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

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 
custom hotkey.

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 
third, etc.

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

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