Bug 353026

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.

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.

Usability, what do you think? Perhaps we could add a "tick" button to the KRunner window like the calendar has?

I wouldn't add complexity. If something has to be sticky it should be implemented as plasmoid. Floating forms should be kept as such.

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.

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

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.

*** Bug 356573 has been marked as a duplicate of this bug. ***

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

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);
     }
 }

+1 i too would really appericate an option to get to old behavior back

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

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.

I think I'll try implementing the "close only if text field is empty or result is clicked (e.g. app launched)" behavior.

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

Patch: https://phabricator.kde.org/D6056

*** Bug 384555 has been marked as a duplicate of this bug. ***

So what is happening with this?

I would love krunner if it did not hide and forget what i was typing...

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

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

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

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!

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

(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

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

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.

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

I really would appreciate a GUI option for this. Like described in #26 closing in focus lost can be really annoing.

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

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.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/333

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

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

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?

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

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.

That is exactly the feature request BUG 397092 which will land in 5.20

This change in behaviour sounds amazing!  Thank you to all involved!  I've missed this since Kubuntu 12.04.

*** Bug 217723 has been marked as a duplicate of this bug. ***