Bug 353026 - KRunner closes when focus is lost
Summary: KRunner closes when focus is lost
Status: RESOLVED FIXED
Alias: None
Product: krunner
Classification: Plasma
Component: general (show other bugs)
Version: 5.4.1
Platform: Compiled Sources Linux
: NOR minor with 120 votes (vote)
Target Milestone: ---
Assignee: Kai Uwe Broulik
URL:
Keywords:
: 217723 356573 384555 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-09-22 05:11 UTC by Chris Spiegel
Modified: 2020-10-11 09:48 UTC (History)
20 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.21
kde: Usability+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Spiegel 2015-09-22 05:11:43 UTC
KRunner (activated with Alt-F2) closes if there is any change in window focus.  I assume this is intentional behavior, but there is, I suspect, an unintended consequence: I have focus follows mouse turned on, which means that if I hit Alt-F2 while I have any windows open, odds are pretty good my mouse will pass through one of those windows if I try to point it at the dialog, causing the focus to change, thus causing KRunner to close.  This is vexing when I have, for example, something in the primary selection and I want to middle-click to paste it into KRunner, or if I want to open the KRunner configuration.  I have to explicitly move my mouse to the top of the screen before hitting Alt-F2, whereas in previous versions I could hit Alt-F2, throw my mouse up, and KRunner would stay open, even if passing through windows caused a focus change.

I consider it a bug that, when focus follows mouse is on, a change in window focus causes KRunner to close.

Reproducible: Always

Steps to Reproduce:
1. Enable focus follows mouse
2. Open some windows
3. Move the mouse pointer near the bottom of the screen
4. Hit Alt-F2
5. Attempt to move the mouse to the KRunner dialog, being sure to pass through some windows on the way up there

Actual Results:  
KRunner closes as soon as the focus changes, i.e. as soon as a window is traversed.

Expected Results:  
KRunner stays open.
Comment 1 Jakob Petsovits 2015-10-15 00:22:23 UTC
Confirmed. I'm running Plasma 5.4 on Arch and prior to 5.4 (or around that timeframe), KRunner remained open after focusing a different window.

This is annoying for me because I often use KRunner as a calculator, where I open it, then copy a different number from a text file (in another window), which I then used to paste again into the KRunner window. This flow is completely broken with a disappearing KRunner, because it doesn't keep its textual content after disappearing and also doesn't keep a history of "unfinished" calculations. As a result, I now have to try and always copy the calculation from the KRunner text field, so that I can afterwards select the new number and paste both of them into the new (blank) KRunner text field. This works with the help of either Klipper or a mix of regular clipboard and middle-mouse-button paste. Either way it's easy to lose track of content that was already in there.

I think it would work better only empty KRunner windows disappeared and a text field with existing text would work like it did before Plasma 5.4, i.e. remain on screen until closed with Esc or its "X" button.
Comment 2 the2nd 2015-11-26 10:54:27 UTC
Just a +1 from me. Not only when using it as a calculator its very annoying. I also use it to put a password into the krunner text box to type it into a remote desktop session when copy/paste is impossible.
Comment 3 Kai Uwe Broulik 2016-02-04 19:13:21 UTC
Usability, what do you think? Perhaps we could add a "tick" button to the KRunner window like the calendar has?
Comment 4 Heiko Tietze 2016-02-04 19:49:30 UTC
I wouldn't add complexity. If something has to be sticky it should be implemented as plasmoid. Floating forms should be kept as such.
Comment 5 Thomas Pfeiffer 2016-02-04 20:35:53 UTC
I agree with Heiko that a "Sticky" function isn't the answer here.
I also agree with Heiko in that KRunner should not be treated differently to other popups in Plasma. One could argue that it's more likely to have the mouse elsewhere when opening KRunner because it's activated by the keyboard, but other Plasmoid popups (e.g. the launcher) can be opened by a keyboard shortcut as well and do in fact suffer from the same problem (I've just tried).

So to prevent "close things by moving the mouse", can't we make it so that KRunner as well as Plasma popups only close when clicking outside of them, but not through "Focus follows mouse"?
That way the situation would still be the same for people who have set "Click to focus" (the default), while preventing accidental closing for "Focus follows mouse" users.
Comment 6 Kai Uwe Broulik 2016-02-04 20:42:06 UTC
> can't we make it so that KRunner as well as Plasma popups only close when clicking outside of them, but not through "Focus follows mouse"?

I have no idea if that is possible, as I guess focus lost is focus lost :)

One thing that I've been running locally for a while is having KRunner not clear its text field when it hides, so when I open it, I see the last search results and everything. Of course, the input field text would be selected so you could still start typing as before. Perhaps that could be a direction to pursuit? Not sure about the privacy implications and annoyance of having a huge window with potentially stale results show up rather than the small search slit.
Comment 7 Thomas Pfeiffer 2016-02-05 00:24:49 UTC
How about this: If the user either presses enter or clicks one of the search results, they are likely to have done what they opened KRunner for, and we can clean the field.
If they haven't done any of that, chances are they're still planning to do something with it, and the content should stay.
Comment 8 Kai Uwe Broulik 2016-03-07 13:05:45 UTC
*** Bug 356573 has been marked as a duplicate of this bug. ***
Comment 9 the2nd 2016-03-07 14:19:43 UTC
(In reply to Thomas Pfeiffer from comment #7)
> How about this: If the user either presses enter or clicks one of the search
> results, they are likely to have done what they opened KRunner for, and we
> can clean the field.
> If they haven't done any of that, chances are they're still planning to do
> something with it, and the content should stay.

I think this was the old behaviour and i dont understand why it has changed. the only improvement to the old behaviour i could imagine is to make krunner close on focus loss if it was opened without typing in something. Everything else results in losing "data" like described in https://bugs.kde.org/show_bug.cgi?id=356573

and even if there is some use case for the new behaviour there should be an option to configure it.
Comment 10 Roman Odaisky 2016-11-06 17:13:18 UTC
Could you please at least make this one-line change, pending future decisions? This way people will be able to change their krunnerrc and get the behavior they want, while everyone else will get the default.

--- a/krunner/view.cpp    2016-11-06 17:16:31.858925163 +0200
+++ b/krunner/view.cpp    2016-11-06 19:04:02.339834141 +0200
@@ -176,7 +176,7 @@
 
 void View::slotFocusWindowChanged()
 {
-    if (!QGuiApplication::focusWindow()) {
+    if (!QGuiApplication::focusWindow() && m_config.readEntry("AutoClose", true)) {
         setVisible(false);
     }
 }
Comment 11 the2nd 2016-11-06 21:34:50 UTC
+1 i too would really appericate an option to get to old behavior back
Comment 12 Lukas Ba. 2017-01-21 18:59:48 UTC
My workaround: If you switch the desktop with the "show desktop" shortcut (or applet) before calling krunner, nothing will steal the focus from krunner because the windows are hidden. Closing krunner will go back from the desktop to what you have done before.

So the only thing that is needed for a workaround is a dbus command that calls the "show desktop" thing and then opens krunner.

qdbus-qt5 org.kde.plasmashell /PlasmaShell toggleDashboard && \
qdbus-qt5 org.kde.krunner /App display
Comment 13 Danut Haiduc 2017-06-01 08:16:01 UTC
KRunner is one of the main reasons I use KDE. It has a calculator, unit conversion, settings search, and system commands. I find it is very useful.

However, the fact that it loses my unfinished input makes me want to cry.

Sometimes I compute something, then want to add something more to the computation (pasting it from somewhere). The moment I select the other expression, everything I typed in disappears. This is incredibly frustrating.

If you can not make KRunner sticky (or at least preserve my input), then I will no longer use KDE.
Comment 14 Kai Uwe Broulik 2017-06-01 08:28:50 UTC
I think I'll try implementing the "close only if text field is empty or result is clicked (e.g. app launched)" behavior.
Comment 15 Danut Haiduc 2017-06-01 08:59:54 UTC
(In reply to Kai Uwe Broulik from comment #14)
> I think I'll try implementing the "close only if text field is empty or
> result is clicked (e.g. app launched)" behavior.

That would be amazing! I am thrilled.
Comment 16 Kai Uwe Broulik 2017-06-01 09:04:49 UTC
Patch: https://phabricator.kde.org/D6056
Comment 17 Kai Uwe Broulik 2017-09-14 09:06:09 UTC
*** Bug 384555 has been marked as a duplicate of this bug. ***
Comment 18 Morgan Leijström 2018-02-28 22:45:14 UTC
So what is happening with this?

I would love krunner if it did not hide and forget what i was typing...
Comment 19 Danut Haiduc 2018-03-06 00:05:56 UTC
(In reply to Morgan Leijström from comment #18)
> So what is happening with this?
> 
> I would love krunner if it did not hide and forget what i was typing...

Because of this very ticket, I switched to i3 (and now use dmenu + Qalculate as a replacement of KRunner).

I had to replace and integrate each desktop component by myself (volumeicon, clipboard manager, desktop background manager...). But after a year or so I have reached a better experience than out-of-the-box KDE.
Comment 20 Lukas Ba. 2018-03-06 00:20:00 UTC
(In reply to Danut Haiduc from comment #19)
> (In reply to Morgan Leijström from comment #18)
> > So what is happening with this?
> > 
> > I would love krunner if it did not hide and forget what i was typing...
> 
> Because of this very ticket, I switched to i3 (and now use dmenu + Qalculate
> as a replacement of KRunner).
> 
> I had to replace and integrate each desktop component by myself (volumeicon,
> clipboard manager, desktop background manager...). But after a year or so I
> have reached a better experience than out-of-the-box KDE.

Please don't post comments in the tone of "This one specific part of KDE doesn't work for me so i switched to a tiling window manager". It's not a helpful comment to make on a bug tracker. Votes are meant to be used instead of posting +1 comments. Also your reaction to switch away from KDE to replace krunner with dmenu is weird because dmenu runs fine in KDE.
Comment 21 Danut Haiduc 2018-03-06 00:25:24 UTC
(In reply to Lukas Ba. from comment #20)
> (In reply to Danut Haiduc from comment #19)
> > (In reply to Morgan Leijström from comment #18)
> > > So what is happening with this?
> > > 
> > > I would love krunner if it did not hide and forget what i was typing...
> > 
> > Because of this very ticket, I switched to i3 (and now use dmenu + Qalculate
> > as a replacement of KRunner).
> > 
> > I had to replace and integrate each desktop component by myself (volumeicon,
> > clipboard manager, desktop background manager...). But after a year or so I
> > have reached a better experience than out-of-the-box KDE.
> 
> Please don't post comments in the tone of "This one specific part of KDE
> doesn't work for me so i switched to a tiling window manager". It's not a
> helpful comment to make on a bug tracker. Votes are meant to be used instead
> of posting +1 comments. Also your reaction to switch away from KDE to
> replace krunner with dmenu is weird because dmenu runs fine in KDE.

You are right, it was irrelevant to talk about my switch to a tiling WM, and I apologize.

However, I think the dmenu + Qalculate suggestion/workaround is still useful, if people are bugged enough to change their keybindings.
Comment 22 kdebugs 2018-09-26 06:25:21 UTC
This patch from 2017: https://phabricator.kde.org/D6056

...appeared to be accepted, and to fix this issue. (From comment #16: https://bugs.kde.org/show_bug.cgi?id=353026#c16 )

I'm not familiar with the procedures, but is something holding it up?

Is there anything we can do to help get it moving?

Thanks!
Comment 23 Michał Dybczak 2018-12-23 17:58:35 UTC
I also noticed it. Krunner closes itself easily when I move my cursor (also focus follow mouse). However, I don't use Krunner so intensely and usually, try to not to touch touchpad or mouse when issuing some action in krunner.

It isn't a big problem for me. Focus follows mouse has many advantages but... disadvantages as well, especially if you want to use global menus. I just have to live with it or adapt (quickly move the cursor so the focus is not changed or don't move it).
Comment 24 Robert Barat (volt4ire) 2020-03-28 15:45:21 UTC
(In reply to kdebugs from comment #22)
> This patch from 2017: https://phabricator.kde.org/D6056
> 
> ...appeared to be accepted, and to fix this issue. (From comment #16:
> https://bugs.kde.org/show_bug.cgi?id=353026#c16 )
> 
> I'm not familiar with the procedures, but is something holding it up?
> 
> Is there anything we can do to help get it moving?
> 
> Thanks!

It looks like there was a problem with the patch (https://phabricator.kde.org/D6056#572826) which hasn't been addressed by the submitter yet. I just pinged them again about it and am hopeful progress can be made
Comment 25 Alexander Lohnau 2020-10-05 13:38:58 UTC
It is intentional that KRunner closes itself when the focus is lost But I really get that that can be annoying. Especially if you launch a program which takes a while to show up, you have already launched a next query and then the focus gets lost :/

But there has been another feature added which might solve the issue, BUG 397092. This allows you to retain the prior search. Meaning that if you accidentally lose the focus for KRunner the last typed query is restored the next time you open it.

Hopefully that works for you :)
Comment 26 kdebugs 2020-10-05 16:51:49 UTC
That's a nice feature, too, thank you for implementing it. AFAICT it will still make using krunner a clumsy experience when you need to adjust the field a lot: every time you want to add or change something in the search field you will have to call up krunner again, move the cursor to the end of the field, etc.

Since the whole point of krunner is speed of workflow, convenience, etc, this would seem to defeat the point of the application.

It seemed like we had a patch at comment #16: https://phabricator.kde.org/D6056  ... it was almost completed and seemed to just need a little tweaking?

I'm also curious about comment #10 which seemed like a very simple one-line fix (but maybe it's not so easy in reality?)

Thanks for the attention to this.
Comment 27 Alexander Lohnau 2020-10-05 16:55:19 UTC
>I'm also curious about comment #10 which seemed like a very simple one-line fix (but maybe it's not so easy in reality?)

We would also need to add a GUI option for this. Should be relatively easy considering that all the design decisions have already been made.
I am not sure if that is a setting we should expose to all users. What do you think @ngraham (Asking for your VDG perspective right now).
Comment 28 the2nd 2020-10-05 17:50:54 UTC
I really would appreciate a GUI option for this. Like described in #26 closing in focus lost can be really annoing.
Comment 29 Robert Barat (volt4ire) 2020-10-05 19:47:59 UTC
I'd also greatly appreciate a GUI option for this, as this bug has been a showstopper preventing me from using KRunner, and even having the new "preserve previous typed string" option only goes part of the way to ameliorating it
Comment 30 Alexander Lohnau 2020-10-07 05:57:28 UTC
I had asked around on VDG and came to the conclusion that making the close button to a pin button would be the best way to solve this issue.
Comment 31 Bug Janitor Service 2020-10-07 08:08:00 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/333
Comment 32 Alexander Lohnau 2020-10-07 15:48:51 UTC
Git commit 7e2c1e687e197fbc0d98b77fa735612d3c317687 by Alexander Lohnau.
Committed on 07/10/2020 at 15:48.
Pushed by alex into branch 'master'.

Toggle display method for KRunner

This introduces a method to toggle the display of KRunner.
With the exception that if KRunner is visible, but not focused it will
get focused again. This is required for the pin feature.

This method is then used for the default invocation using the shortcut.

M  +2    -0    krunner/dbus/org.kde.krunner.App.xml
M  +1    -1    krunner/krunner.desktop
M  +1    -1    krunner/view.cpp
M  +1    -1    krunner/view.h

https://invent.kde.org/plasma/plasma-workspace/commit/7e2c1e687e197fbc0d98b77fa735612d3c317687
Comment 33 Alexander Lohnau 2020-10-07 15:57:55 UTC
Git commit 0004a1f83b909a04414c56b6519645f1eae62dfd by Alexander Lohnau.
Committed on 07/10/2020 at 15:57.
Pushed by alex into branch 'master'.

Implement Pin feature for KRunner
FIXED-IN: 5.21

For this the close button has been replaced with a checkable button which pins the window. Just like in the system tray.

M  +16   -1    krunner/view.cpp
M  +6    -0    krunner/view.h
M  +7    -7    lookandfeel/contents/runcommand/RunCommand.qml

https://invent.kde.org/plasma/plasma-workspace/commit/0004a1f83b909a04414c56b6519645f1eae62dfd
Comment 34 kdebugs 2020-10-07 17:37:24 UTC
Thanks Alexander! I'm curious about how the workflow looks with that solution: when the pin is activated, does ESC still make the window disappear? And if F2 invokes krunner again, the window appears again, but with the pin still active? Or will it be required to activate the pin every time krunner appears?
Comment 35 Alexander Lohnau 2020-10-07 17:41:05 UTC
(In reply to kdebugs from comment #34)
>when the pin is activated
Only when you click it
>does ESC still make the window disappear?
Yep

>And if F2 invokes krunner again, the window appears again, but
> with the pin still active? Or will it be required to activate the pin every
> time krunner appears?

The pin will be active until you disable it.

And if you have KRunner pinned and go to another window and invoke KRunner it will regain its focus.
Comment 36 kdebugs 2020-10-07 17:46:25 UTC
Brilliant, thank you!

I wonder about Kai's suggesting in comment #6 as well. Probably out of the scope for this bug, but might be a nice addition as well.
Comment 37 Alexander Lohnau 2020-10-07 17:48:47 UTC
That is exactly the feature request BUG 397092 which will land in 5.20
Comment 38 tdowg1 2020-10-09 04:09:23 UTC
This change in behaviour sounds amazing!  Thank you to all involved!  I've missed this since Kubuntu 12.04.
Comment 39 Alexander Lohnau 2020-10-11 09:48:42 UTC
*** Bug 217723 has been marked as a duplicate of this bug. ***