KDE4.4.0: Krunner does not appear when I press Alt-F2
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
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
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.
More info: http://www.kde.org/faq.html.
More information about the kde