I have dual monitor with a vertical panel on the left side of my right monitor. This essentially puts my panel in the center of two monitors. Yakuake only responds to F12 command to open when my mouse is hovering on the right monitor. If my mouse is moved over to the left monitor, Yakuake does not open. It does not matter where the active window is only where the mouse is located. When I move the panel to the left side of the left monitor, Yakuake works on both monitors (opening on whichever one has the mouse open). Kubuntu 18.04 KDE Frameworks 5.44.0 Qt 5.9.5
Duplicate of bug 383555?
I have run into this same bug.
I suspect this bug is different and much simpler than bug 383555 that bug sounds like scaling related. This multi-monitor bug is just that Yakuake won't pop up left of a screen with a vertical KDE taskbar panel on the left, and won't pop up right of a screen with a vertical taskbar panel on the right.
To clarify, my vertical task bar is on the right screen. When my mouse or any window is active on my left monitor, Yakuake will not open. I have to click on a window on the right screen, then it will respond.
I have a triple screen setup, so the description in Comment #3 is fairly precise. Depending on where I move the vertical kde taskbar, it blocks Yakuake. It seems that Yakuake assumes nothing can be beyond the edge where the kde taskbar resides.
The problem is that getDesktopGeometry returns 0,0,0,0 for width,height,x,y on the offending monitors. Looking at that function, I might actually figure it out here.
A hack that worked for me, changing the one line to: return KWindowSystem::workArea(/*offScreenWindows*/).intersected(screenGeometry); Allows yakuake to pop up on the monitors that it currently refuses to. I don't know what the proper fix is. In my case, offScreenWindows is an empty list, but it's also an empty list on the working monitors. I don't really understand what's going on in the code that's looking at "window struts".
When I print out the values of KWindowSystem::workArea(offScreenWindow) it's clear that width value is broken. It says 1774 with the parameter, and 9600 without a parameter or -1 as the default parameter. My desktop is 9600 wide (3840+3840+1920). Also the x value is wrong. When I move the KDE taskbar to a horizontal edge, then the values are good BUT there is also an offscreenWindow. I think the solution might be: if (offscreenWindows.isEmpty()) return KWindowSystem::workArea().intersected(screenGeometry); return KWindowSystem::workArea(offscreenWindows).intersected(screenGeometry);
This blog talks about some problems with having the KDE panel on a shared screen edge and struts: https://blog.martin-graesslin.com/blog/2016/08/panels-on-shared-screen-edges/
Yes, this is the correct solution, I see now. Please apply this change! if (offscreenWindows.isEmpty()) return KWindowSystem::workArea().intersected(screenGeometry); return KWindowSystem::workArea(offscreenWindows).intersected(screenGeometry);
Thanks Jason for the investigation. Developers will review your patch if you add it to https://phabricator.kde.org/differential/diff/create/ For more information, please see https://community.kde.org/Get_Involved/development#Submit_your_patch
Jason, any luck with the links from comment #11?
Can the assigned developer Eike Hein pass the suggested patch in comment 10 to the yakuake developers please?
Eike is the yakuake developer. There is a bigger chance to get his attention if you submit the patch for review to phabricator, see comment #11.
This needs a bit more investigation - `KWindowSystem::workArea` shouldn't return something different when passing in an empty list vs. passing in nothing. The real fix might need to be done there.
Eike, thanks for commenting -- this is why I didn't want to submit a patch. Although I can see something is wrong, and could hack something to work on my system, I don't know what the proper fix is.
Investigation is half the battle, thanks for this! One of the reasons I've been ignoring this issue for so long, to be honest, is that I moved 8500km and spent the last three years with only a laptop - no multi-monitor. But over the last few months I bought first a TV, and now a new laptop with a painfree-working HDMI-out. I can finally test this now and will move it higher on my todo, sorry for the wait!
This bug may be connected to Panels somehow: I have almost the same layout as Ryan: two monitors side by side and vertical panels on the left side on both monitors. What i've noticed: 1. If i move panel to the right side on my right monitor (primary), everything works. Deeper investigation shows that the problem is possibly related with KWindowSystem::workArea as Christoph noticed: with such monitors-panels-layout it gives only right part of the desktop, but calling it without passing offScreenWindows is not the best solution: it gives combined area of both monitors restricted to only the most left panel, so on the left monitor yakuake gets an offset from the panel while on the right it has no offset thus making its appearance non-consistent. To summarize with KWindowSystem::workArea(offScreenWindows) if offScreenWindows empty: 1. [vpanel| secondary monitor][vpanel| primary monitor] : gives only right part 2. [vpanel| secondary monitor][primary monitor |vpanel] : gives full desktop area
I did a little bit of investigation and the problem seems to be that if you have a panel on your right monitor attached to the left side, Plasma creates a x11 strut area, which essentially spans over your entire left monitor. This leaves no space for yakuake to open on that monitor. Not 100% sure what the best way to handle this is, because using workArea with the list argument - I think - is actually the correct implemented one. As a quick fix you could set in your panel settings "Windows can go cover".
Just created a Merge Request which hopefully should fix this issue. https://invent.kde.org/utilities/yakuake/-/merge_requests/6 Since multi-monitors bugs are kinda hard to confirm on every type of setup, it would be great if a couple of people could test this mr if it fixes the issue on their side and didn't introduce any regressions.
That works! Thanks Maximilian! I'am switching to that branch for now since i'am not noticing any regressions.
commit df1e7230410516816b3f3e5b93d463d779fe3ae0 Author: Maximilian Schiller <manimax3@outlook.de> Date: Sat May 30 21:52:54 2020 +0200 Fix yakuake not opening on multimonitor setups Fixes yakuake not opening on one monitor when the panel is located on an edge between two monitors. This patch corrects the ExtendedStruct calculations and then checks if not only the strut intersects with the current monitor but also the window frame. If the strut intersects but the window frame does not that window is most likely some king of panel located on an edge between the current and the next screen. With this patch those struts and windows will now be ignored. 12 7 app/mainwindow.cpp https://invent.kde.org/utilities/yakuake/commit/df1e7230410516816b3f3e5b93d463d779fe3ae0
*** Bug 401769 has been marked as a duplicate of this bug. ***
*** Bug 414322 has been marked as a duplicate of this bug. ***
*** Bug 416382 has been marked as a duplicate of this bug. ***
*** Bug 424746 has been marked as a duplicate of this bug. ***