KDE4.4.0: Krunner does not appear when I press Alt-F2

Duncan 1i5t5.duncan at cox.net
Thu Feb 11 00:23:08 GMT 2010

Andrea Scarpino posted on Wed, 10 Feb 2010 23:52:39 +0100 as excerpted:

> On Wednesday 10 February 2010 23:33:42 Paul Hartman wrote:
>> After upgrading to KDE 4.4.0 the Krunner doesn't appear when I press
>> Alt-F2. However, if I "killall krunner" from a terminal, then run
>> krunner again, Alt-F2 works after that (Krunner appears on my screen).
>> How can I figure out the reason why? Does this happen to anyone else?

> here on Arch Linux we had the same issue. Downgrade soprano to 2.3.73
> solve that. I think we had that issue because we built KDE 4.4.0 with
> soprano 2.3.73.

Interesting solution.  I have similar symptoms, but with a variation, here 
on Gentoo.  I first noted this back a few kde updates... perhaps 4.3.1 or 
4.3.3 (earlier than 4.3.1 I was still converting from 3.x and had too much 
stuff not yet working to notice).  It has happened once with 4.4.0 now 
already, the first time I tried krunner, but I did the usual thing and it 
went away.  I've not rebooted to know if it comes back yet, or if that was 
just due to the upgrade and it's gone now.  Here's how the variant I have 

Note that I have one of those keyboards with "extra" keys (media keys, 
internet keys...).  I have krunner's shortcut reassigned from Alt-F2 to 
one of them, but I don't believe it matters.

Sometimes, I'll note that the krunner keyboard shortcut just doesn't seem 
to work.  No response from either the assigned shortcut or the default alt-
F2.  But if I launch it from kickstart or from the desktop context menu, 
it launches fine, and the keyboard trigger works for it again after that 
as well.

It's as if krunner normally stays running in the background, ready to 
launch with the keyboard trigger.  Sometimes, for whatever reason, it 
either crashes or fails to start, so the keyboard trigger doesn't work.  
The desktop or kickoff launchers (both actually being plasma) probably try 
to launch it that way first (using dbus calls or whatever), but are smart 
enough to launch it directly if the dbus calls or whatever fail, thus 
restarting it, so it's listening in the background once again.  But the 
keyboard launch trigger doesn't have the launch directly fallback, so if 
the dbus call or whatever fails, there's simply no visual response at 
all.  But once it's restarted by plasma, it's running again, so the dbus 
or whatever calls work properly again, thus, the keyboard trigger works 

As noted, this has been happening to me occasionally since sometime in the 
4.3 series at least, and likely as long as I've been running kde4, I just 
didn't notice it before that as there was too much else broken, that one 
bit of disfunctionality was lost in the noise.

So, the next time the keyboard trigger fails to work, see if it'll launch 
from kickoff/lancelot or from the desktop context menu, and if so, if that 
fixes the keyboard trigger too.  It may be that the soprano downgrade 
didn't have a lot to do with it after all, krunner was just left 
responding after that, as it is when launched from plasma.  Or it may be 
that soprano /was/ implicated in your cases, and I've either found a 
different workaround, or am seeing another issue that just happens to have 
similar symptoms.

Regardless, since I discovered that launching krunner from plasma works 
and fixes the temporary keyboard trigger issue as well, the issue hasn't 
been high enough on my radar to worry about it, or even really be aware of 
it, certainly not enough to post about it, until I saw this thread.  Now 
I'm wondering if it's the same issue, or not.

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.

More information about the kde mailing list