My setup includes two displays at different resolutions. Note that I configured Yakuake to open in the screen containing the cursor. I encountered a few issues: 1. I've set up a KWin keyboard shortcut to move a window to the next screen. When used on yakuake, the window is not resized accordingly. This is fixed by the change in MainWindow::moveEvent. The showNormal() call is necessary in some cases, e.g. when the window covers the entire screen it was moved to. This is NOT the only case and I couldn't figure out the exact behavior. Calling showNormal every time was an easy solution... The change in getScreen is also necessary for this to work (the new screen doesn't necessarily contain the cursor). I hope it didn't break anything. A side-effect of this fix is that dragging the yakuake window into another screen is "hard": it will bounce back and forth between the cursor position and the original position until the cursor is way into the next screen. I'm not sure how to fix this. 2. If I open yakuake on either screen it gets the correct height, but when I choose a height from the menu (only on the larger screen? hard to tell) it would get a much smaller height than expected. This is fixed by the changes in MainWindow::getDesktopGeometry. 3. Sometimes when a terminal app changes appearance on SIGWINCH, the terminal will be jumbled up if I retract yakuake on one screen and open it on the other (example: vim shows a startup message, version etc., when started, which is deleted on SIGWINCH). This was fixed by adding update() in MainWindow::xshapeOpenWindow.
Created attachment 60916 [details] see above
Sorry, can't accept/apply this patch as is: 1. The existing code in moveEvent() is there precisely to resize the window when it is moved between screens, including via the kwin shortcut - that's exactly what it was written for, so of course I verified that it works :-). I don't have two monitors at the moment, though; if you claim that it stopped working I have to organize a second one first so I can verify that and then come up with a fix that doesn't have the side-effects you describe, which don't seem acceptable. 2. This looks like a good fix, will probably apply after testing (don't have access to my dev environment tonight sadly). 3. Tried a single update at the end? On every frame seems likely to make the animation performance quite horrid (which tends to cause users to scream at me :-).
Thanks for the quick reply! 1. The existing code does not resize the window when yakuake is configured to open "at mouse location" (Settings::screen() == 0)) 2. Hooray! 3. Actually I did. With your solution (though I agree it's much better performance-wise) the terminal will appear jumbled up until the last frame of the animation. It's pretty noticeable...
Meh, looks like #2 isn't really solved. Will look into it.
How's it going? :)
Created attachment 62395 [details] take two Here's a revised patch. 1. I rewrote the moveEvent fix. It now find the screen number by looking at the center of the window. This avoids the awkward side-effects I mentioned. 2. I rewrote the strut handling code. It works now, and it also takes bottom struts into account. 3. Regarding the addition of update(): update doesn't cause an immediate repaint, but instead schedules one. On slow systems, several updates may result in a single paintEvent (see Qt docs). There's one remaining issue that I have also been able to reproduce *without* my patch. When dragging the window from one screen to the other, it will move to the new location with the new size once most of the window is in the new screen. Then, in some cases, if you keep dragging, the window will be resized to the original size, while the child widgets still have the new size. It looks like the X server sends the window size as well as the new location of the window with every drag (a ConfigureNotify event), and keeps sending the same size even if you resize the window during the dragging.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
(In reply to Andrew Crouthamel from comment #8) > Dear Bug Submitter, > > This is a reminder that this bug has been stagnant for a long time. Could > you help us out and re-test if the bug is valid in the latest version? This > bug will be moved back to REPORTED Status for manual review later, which may > take a while. If you are able to, please lend us a hand. > > Thank you for helping us make KDE software even better for everyone! This bug is not solved so far. My laptop connect to an external 4K monitor, and I disabled the built-in monitor (1080P). when setting the yakuake window size to 100% and 100% for width and height (with a scaling factor of 1.5 for the 4K monitor), the Yakuake window cannot fullfill the whole screen.
Created attachment 123352 [details] scaling 1.2, 100% width, 100% height I have the same issue on a x250 (HD Graphics 5500) on plasma 5.17 (but the issue exists already longer..). I've set both height and width to 100%, but yakuake is filling only ~80% of the screen when popping up, scaling is 1.2. If I increase the scaling, the width/height is reduced accordingly. Setting manually fullscreen, however, works.
I've played around a bit, and it seems that the KWindowSyste::workArea() is not working as expected -- at least on scaled (and/or multi-head) setups. What kind of works better is simply returning screenGeometry always in MainWindow::getDesktopGeometry(), it seems to be a bit more reliable, ie. doing the same for wayland and x11: if (m_isWayland || true) { // on Wayland it's not possible to get the work area return screenGeometry; } Then the window will overlap the panel if the height is 100%, but I can set the height to 90%, but then get a working yakuake on dual-screens with scaling
The solution from Nicolas also works for me! My display setup is: ┌-----------┐┌----------------------┐┌-----------┐ | 1920x1080 || || 1920x1080 | └-----------┘| 3840x2160 |└-----------┘ | | └----------------------┘ ...and the 1080p monitor on the right is scaled by xrandr --scale 2.0 yakuake previously can only take half of the height on my 2160p monitor and doesn't show up on the 1080p one on the right. After rebuilding it with the fix everything now works like a charm! Thanks, Nicolas!
May I know what prevents Nicolas's patch from being merged? I've been patching Yakuake locally every time it got upgraded for almost a year now.
(In reply to Frederick Zhang from comment #13) > May I know what prevents Nicolas's patch from being merged? I've been > patching Yakuake locally every time it got upgraded for almost a year now. Nothing, I guess. The problem is probably that nobody went ahead and submitted a merge request for it. I'd appreciate if you or somebody else went ahead and created one with the patch. Let me know if you need assistance.
As the patch seems to be working better also for other people, I can clean up the patch and prepare a proper merge request for the change
(In reply to Nicolas from comment #15) > As the patch seems to be working better also for other people, I can clean > up the patch and prepare a proper merge request for the change Thank you!
(In reply to Nicolas from comment #15) > As the patch seems to be working better also for other people, I can clean > up the patch and prepare a proper merge request for the change That would be great!
A possibly relevant merge request was started @ https://invent.kde.org/utilities/yakuake/-/merge_requests/27
I started watching this thread, as I struggle daily with KDE to just maintain some sanity with a dock/undock scenario with various displays. Multi-monitor has been dysfunctional since 4.x kde days, and it seems still is. I use a laptop as my main rig now with a TB3 dock adding 2x 4k displays. Anytime this changes, KDE simply loses my settings, totally forgets, craps the bed, crashes compositing, about whatever you can imagine it might do poorly, it does. Not that most DE's are much better, KDE is particularly confounding. If I dock, setup display manager for 3x 4k/60hz displays accordingly, I expect it knows to revert back to that when it sees the dock and displays attached. Instead it goes bonkers, reverts randomly to who knows what, and tends to just reset settings in weird ways. Sometimes the dock or DP-to-HDMI adapters reset to odd resolutions (like 1080p only), which freaks it out even worse, but it's random how KDE responds to reconfigure the desktop, and usually horribly. I cannot get KDE to act the same way twice in any scenario display/resolution-wise. Why it cannot, is beyond me other than bugs or unexpected behaviour, which for a laptop is not to be unexpected jacking into random displays extensions. Even the same setups reset every time, so it's 50 first dates every time I connect my display. It resets resolution, position, refresh rate, sometimes randomly mirrors, just all over the place. Even more confounding, my displays reverse, randomly it disables my main laptop displays, and other things I just can't rationalize other than being possessed by a spirit of chaos. The worst thing is when I happen to accidentally power off a display, to bring it back up, and it starts hiding my windows. Since being TV displays, I use a remote to power them up/down, and occasionally it shuts off the wrong display. My TB3 dock can only use 2x of the displays, so my 3rd I use for other things. If the remote powers down the display, it really freaks KDE out that I simply cannot use the display. Shutting off the display while connected will cause KDE/xrandr to reposition things as it sees a temporary change, but even bringing it back online, if I move a window to that display, it hides it entirely as though offscreen. This is the freakin' worst, as it is unresolvable without a hard reboot, even restarting sddm will not resolve. This is super hard to explain how much grief KDE gives me with multi-monitor. Compositing in KDE is the worst at full 3x 4k display resolution, even youtube stttttuddddddders constantly on a fresh reboot to make it almost unusable, but the compositing itself behaves randomly. KWin crash randomly, which is apparent immediately, and restarting it from display settings/compositing, disabling it will enable it, and vise-versa oppositely. Almost every aspect of display settings from resolution to monitor alignment to compositing is buggy to control in a predicable fashion. The KDE display subsystem is just simply dysfunctional. I've tried digging for significant log events or anything to tip me off to something easily resolvable, but there is nothing. Xrandr looks good, just KDE can't seem to manage display settings consistently for whatever reason.
(In reply to Michael Butash from comment #19) > I started watching this thread, as I struggle daily with KDE to just > maintain some sanity with a dock/undock scenario with various displays. > Multi-monitor has been dysfunctional since 4.x kde days, and it seems still > is. > > I use a laptop as my main rig now with a TB3 dock adding 2x 4k displays. > Anytime this changes, KDE simply loses my settings, totally forgets, craps > the bed, crashes compositing, about whatever you can imagine it might do > poorly, it does. Not that most DE's are much better, KDE is particularly > confounding. > > If I dock, setup display manager for 3x 4k/60hz displays accordingly, I > expect it knows to revert back to that when it sees the dock and displays > attached. Instead it goes bonkers, reverts randomly to who knows what, and > tends to just reset settings in weird ways. Sometimes the dock or > DP-to-HDMI adapters reset to odd resolutions (like 1080p only), which freaks > it out even worse, but it's random how KDE responds to reconfigure the > desktop, and usually horribly. > > I cannot get KDE to act the same way twice in any scenario > display/resolution-wise. Why it cannot, is beyond me other than bugs or > unexpected behaviour, which for a laptop is not to be unexpected jacking > into random displays extensions. > > Even the same setups reset every time, so it's 50 first dates every time I > connect my display. It resets resolution, position, refresh rate, sometimes > randomly mirrors, just all over the place. Even more confounding, my > displays reverse, randomly it disables my main laptop displays, and other > things I just can't rationalize other than being possessed by a spirit of > chaos. > > The worst thing is when I happen to accidentally power off a display, to > bring it back up, and it starts hiding my windows. Since being TV displays, > I use a remote to power them up/down, and occasionally it shuts off the > wrong display. My TB3 dock can only use 2x of the displays, so my 3rd I use > for other things. If the remote powers down the display, it really freaks > KDE out that I simply cannot use the display. Shutting off the display > while connected will cause KDE/xrandr to reposition things as it sees a > temporary change, but even bringing it back online, if I move a window to > that display, it hides it entirely as though offscreen. This is the > freakin' worst, as it is unresolvable without a hard reboot, even restarting > sddm will not resolve. > > This is super hard to explain how much grief KDE gives me with > multi-monitor. Compositing in KDE is the worst at full 3x 4k display > resolution, even youtube stttttuddddddders constantly on a fresh reboot to > make it almost unusable, but the compositing itself behaves randomly. KWin > crash randomly, which is apparent immediately, and restarting it from > display settings/compositing, disabling it will enable it, and vise-versa > oppositely. Almost every aspect of display settings from resolution to > monitor alignment to compositing is buggy to control in a predicable fashion. > > The KDE display subsystem is just simply dysfunctional. I've tried digging > for significant log events or anything to tip me off to something easily > resolvable, but there is nothing. Xrandr looks good, just KDE can't seem to > manage display settings consistently for whatever reason. I just skimmed through your pretty long text. It does not really seem to be related to this issue, if I am not mistaken. The title of this bug might be pretty broad, but that does not mean that all multimonitor problems are tracked here. There might be already opened specific bug reports for your problems. If not I encourage you to open them yourself. Most problems are probably rooted in KWin.