Bug 448572 - KRunner always appears on top-most and/or left-most screen, not the screen with the cursor on it
Summary: KRunner always appears on top-most and/or left-most screen, not the screen wi...
Status: RESOLVED DUPLICATE of bug 427069
Alias: None
Product: krunner
Classification: Plasma
Component: general (show other bugs)
Version: 5.23.90
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Alexander Lohnau
URL:
Keywords: wayland
Depends on:
Blocks:
 
Reported: 2022-01-15 23:40 UTC by indecisiveautomator
Modified: 2022-03-27 11:38 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description indecisiveautomator 2022-01-15 23:40:52 UTC
SUMMARY
Several Plasma components such as KRunner and notifications do not respect the Primary display option and insist on showing up on the monitor plugged into the first displayPort on my GPU (DP-01).


STEPS TO REPRODUCE
1. Get a notification on Plasma or activate KRunner. Likely also affects other Plasma components.
2. Will appear on display that is the display plugged into the first port on your GPU and not the display marked as primary.


OBSERVED RESULT
Plasma components do not respect primary monitor setting.


EXPECTED RESULT
Plasma components such as notifications and KRunner should either appear on the primary display. KRunner likely should appear on the display that your cursor is on, but other plasma components do not respect the Primary display setting either when they likely should.


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.16.0-arch1-1
KDE Plasma Version: 5.23.90
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
In my use case, my primary monitor is unfortunately a monitor in the top corner of my setup, meaning it is easy to miss notifications and inconvenient to look up and use KRunner on it every time.
Comment 1 Nicolas Fella 2022-01-16 13:12:20 UTC
Notification placement has nothing to do with what the primary monitor is. Notifications appear on the screen where the notification applet is placed
Comment 2 indecisiveautomator 2022-01-16 16:13:49 UTC
I'm not sure I have a specific notification applet apart from the one in the system tray, which I have in each of my 4 panels on each display. Maybe this should be a separate report, I remember seeing discussion before around where notifications should appear and I just assumed from a user perspective that they would appear on the primary display.

Notifications used to appear on my the top middle display, as it was in the DP-02 port. Now that there is a display in the DP-01 port, it seems to be the one that takes priority for notifications and KRunner. I had thought setting the primary display would change this behaviour.
Comment 3 Marco Martin 2022-01-18 15:37:04 UTC
for both krunner personally i would prefer it to appear on the screen with a currently focused window (notifications when there is an applet per display i guess that would also apply, otherwise yeah, whatever the screen with the applet)
Comment 4 Marco Martin 2022-01-18 15:41:11 UTC
krunner at he moment tries to appear in the screen with the cursor in it, but this of cource can only work on x11, so on wayland that's broken, and will always appear on the screen that contains 0,0 in its geometry, so the left-most
Comment 5 Nate Graham 2022-01-20 23:08:49 UTC
For notifications, see Bug 446961.

Let's use this bug report to track the issue with KRunner.
Comment 6 indecisiveautomator 2022-01-20 23:12:46 UTC
Just for what it's worth with the renaming of this bug: KRunner does *not* always appear on the left-most screen. It always appears on the screen with 0,0 I believe, but that isn't always the left-most. In my case, I have a monitor in the top middle which i will assume is 0,0 however this is the screen that KRunner appears on. So in some setups, the title of this bug is inaccurate.
Comment 7 Nate Graham 2022-01-20 23:24:25 UTC
Oh wow.
Comment 8 Kishore Gopalakrishnan 2022-03-27 11:38:55 UTC

*** This bug has been marked as a duplicate of bug 427069 ***