[kde-linux] [SOLVED with thanks] Re: Alt-F1 shortcut (Kicker) disappears

Bruce Miller subscribe at brmiller.ca
Sat Apr 17 16:32:50 UTC 2010

Reply bottom-posted
As happens too often, I forgot to set the correct identity before posting this reply the first time. That reply was bounced. I have tried to stop it; if it slips through and this message ends up double-posted, please be forgiving.

----- Original Message ----
> From: Duncan <1i5t5.duncan at cox.net>
To: kde-linux at kde.org
> Sent: Sat, April 17, 2010 11:21:59 AM
> Subject: Re: [kde-linux] Alt-F1 
shortcut (Kicker) disappears
> 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 

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 
keyboard and mouse, global keyboard shortcuts.  Select 
> 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 
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, 
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 
> 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 
the ~/.kde tree as you mentioned, then in 
> the 
working version (not the 
backup), delete roughly half the 

Start kde and see if the problem's still there or is 
> (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, 
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 
(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 
and half of the half you know WAS the 
> problem.

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 
> 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 
time, based on name and narrowing missing functionality, you 
> 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 
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 
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 
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 
level, the individual configuration item.

Now some 
general bisect method observations, based on experience.  The 
> times you do it, it'll be hard.  But as you get more 
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 
> 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 
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, 
you decide to do so.

> important exception 
to remember is that some of the newer apps and 
> 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 
> 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 
> or if one is crashing, so you know where to 
start your bisect as 
> above.  You can check the strace and grep 
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 
like that really DOES give you an appreciation 
> of 
just how much work your 
computer is doing behind the scenes!

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

2>&1 bit is important, as strace's output normally 
appears on STDERR, 
not STDOUT, so it won't get piped to grep unless 
> redirect STDERR (file 
descriptor 2) to STDOUT (file 
descriptor 1).

> a more real example, try this (replace /home/user as appropriate):

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

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

Thank you for the very 
helpful reply.

While I haven't necessarily solved the problem, I 
discovered the dead-simple workaround:
- using the mouse, bring up 
- right-click on the K application launcher icon;
- choose application launcher settings| Keyboard shortcut;

As I feared, 
the Keyboard shortcut was "None." It was a trivial task to re-enter it.

Your bisection method makes such obvious good sense that I was tempted to 
smack my forehead in frustration and shout out loud, "Why didn't I think of that?' And all this time, I had never actually blown away the ~/.kde tree. I always renamed it and moved it to a "cool dry corner" of the 
home directory.

Kubuntu's implementation of the KDE4 control is 
called "SystemSettings" (with no space between the two English words). 
Under the drop-down for keyboard and mouse | global keyboard shortcuts | plasma-workspace there is no entry for an  Application Launcher Widget. The only entry is for the Widget Dashboard. Nor do I find a reference 
anywhere else in the large SystemSettings context to defining a keyboard shortcut for Kicker. Since this appears to be a question of Kubuntu's 
implementation of the KDE function (and not a core matter within KDE 
itself), should I be filing a bug report on Launchpad (the Ku/Ubuntu bug tracker)?

Thanks once again for all the help.


Bruce Miller, Ottawa, Ontario, Canada
bruce at brmiller.ca; (613) 745-1151
Just when you think your software is idiot proof, somebody comes up with a better idiot
Keyboard not found...Press any key to continue.

----- Original Message ----
> From: Boyd Stephen Smith Jr. <bss at iguanasuicide.net>
> To: For people using KDE on Linux with related questions/problems <kde-linux at kde.org>
> Sent: Sat, April 17, 2010 11:35:21 AM
> Subject: Re: [kde-linux] Alt-F1 shortcut (Kicker) disappears
> In <
> href="mailto:126762.5191.qm at web88305.mail.re4.yahoo.com">126762.5191.qm at web88305.mail.re4.yahoo.com>, 
> Bruce Miller wrote:
>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").

Kicker was an application in KDE 3.x that provided one or more 
> docked panels.  
It wasn't the only one for KDE 3.x.

In KDE 4.x 
> there is no more kicker application.  Instead the panels are 
handled by 
> the same thing that handles wallpaper and widgets: plasma-desktop.

As far 
> as Alt+F1, I seem to remember that it works with "Application Launcher 
> and "Lancelot", but that "Application Launcher" (the default) has issues 
with it.  You should read the archives, it came up earlier this 
> year.
Boyd Stephen Smith Jr.            
>        ,= ,-_-. =.

> href="mailto:bss at iguanasuicide.net">bss at iguanasuicide.net    
>                ((_/)o o(\_))
ICQ: 514984 
> YM/AIM: DaTwinkDaddy         `-'(. .)`-'

> href="http://iguanasuicide.net/" target=_blank 
> >http://iguanasuicide.net/              
>       \_/

More information about the kde-linux mailing list