This is a minor issue, and I am not 100% where to report it. Please forward as you the expert see fit. And of course I strongly apologise if this has already been reported. I tried to look through the current bug reports. I have an external monitor, which I connect to my docking station of my laptop and run dual monitor. The laptop being physically positioned lower than the external screen, it is then natural to align the bottom of the screens instead of the perhaps more traditional top of the screens. Please see screenshot of my setting in [1]. Now, the problem seems to be that the logic believes that the top of my external, larger monitor defines the top of all screens. In particular, if a new window is opened on my laptop screen (left side), the top part of the window is inaccessible, see [2]. This example shows when I click "new message" in Thunderbird. Note that the screenshot here is taken all the way up to the top of the laptop screen, so there is obvious way to move the window. Finally, this is for me personally a very minor problem, but I thought you wanted to improve it long term (for a usability perspective it does look clumsy). I know that I can right click on the windows icon in the panel, and select "move" from there. Or I can simply not organise the screens in this particular order. [1] https://dl.dropboxusercontent.com/u/2293502/2015-05_kwin_err_1.png [2] https://dl.dropboxusercontent.com/u/2293502/2015-05_kwin_err_2.png Reproducible: Always Steps to Reproduce: 1. Connect two monitors, one larger than the other. 2. In settings, align the screens along the bottom of each respective one (so top is not aligned) 3. Open a window on the smaller screen. 4. (it could be that the larger screen must be to the left of the smaller?) Using Chakra GNU/Linux, KDE 4.14.8 $ uname -a Linux <hostname> 3.19.4-1-CHAKRA #1 SMP PREEMPT Mon Apr 13 18:25:23 UTC 2015 x86_64 GNU/Linux
> Thunderbird Have you ever spotted this with a NON-mozilla client? The client will likley request the window in that position or perform a configure request to move the window there (mozilla clients have a record on this...) and kwin will forbid to completely move windows out of sight, but not partially. Can you please setup a window rule (for that window or all thunderbird windows) that in "size and position" says "ignore requested geometry" / "force" / "yes" - ? In case this should not work, please a) export the rule you created and attach it here b) post or attach the output of "xrandr -q" on this bug. Thanks.
Hi, I forget exactly which applications have shown this behaviour, but in general I have noticed that when I am moving around a window I am allowed to cross the top border of the screen in this configuration. However as my mouse is holding on the top bar of the window, this doesn't go far beyond the top screen. Normally in KWin I think that if you try to push any window beyond the top border it will not allow you to do so? The reason I used Thunderbird for the example is that it seems to consistently open the window on my smaller display (at least when the main window is there). I also tried to e.g. open a new Dolphin or similar, but it always opened on my left screen (where no issues are found). I will try the suggestion as soon as I have time (this is my private computer at home which I do not have a lot of time to play around with these days).
When you drag the window, it will shortly stop at the top edge, but if you insist (push more) it will go beyond (until the pointer reaches the border) - if you move w/ alt+lmb, there's even no short stop. After all _you_ want the window to be there, and that's what matters. It's however unrelated to the described situation. KWin will place windows on the "active" screen, which is either the screen with the mouse or the active window on it (configurable in "kcmshell4 kwinoptions")
I am not so sure it is unrelated. This behaviour of 'shortly stopping', does *not* happen on my smaller screen with the configuration described, but it will happen on my larger screen, and on both screens if they are aligned along the top edge instead. My initial thought was that the window system "believed" on some level that the top edge of both screens is defined according to the larger screens top edge. But the mouse is not allowed to travel beyond the edges of any screens, as expected.
Can you please attach the outputs of qdbus org.kde.KWin /KWin supportInformation and xrandr -q then?
Created attachment 92894 [details] output of qdbus org.kde.KWin /KWin supportInformation
Created attachment 92895 [details] output of xrandr -q
> Screens > ======= > Active screen follows mouse: no KWin should place windows where the active window is. > Number of Screens: 2 > Screen 0 Geometry: 1920,300,1600x900 > Screen 1 Geometry: 0,0,1920x1200 Looks as expected. Please add the rule for thunderbird and check how it behaves with that.
Hi, Sorry, this bug comes and goes a bit, and I don't know the precise way to reproduce always. That said, it has happened frequently enough that I felt it was worth reporting it. I now had the same issue suddenly with Okular so I decided to do a quick screen grab to show you: https://dl.dropboxusercontent.com/u/2293502/2015-05_kwin_err_3.ogv You see in the video that recordmydesktop actually see the full frame of the window but it is outside the screen. I am trying with the mouse to go to the top and drag the window down, to demonstrate where the edge is. I had tried the "force window geometry" suggestion of yours with Thunderbird, but then I realised that the window suddenly behaved "behaved correctly" during that test. I tried to set the force rule now with Okular, but that did change anything in the behaviour.
Since KWin does not position windows outside screen bounds ;-) I could assume that a) the rule for okular is too strict (eg. includes title) b) okular starts with/has a minimum size requirement (where at hand i'd say the window should be positioned on the other screen or at least ensure to keep the deco in sight) Can you please export and attach your okular rule and/or try to also rule to "obey geometry restrictions" "force" "no"?
Could you please attach the rule as requested in comment #10?
Sorry I do not anymore have access to the system which was producing this bug. If you are unable to reproduce (and no one else has reported this issue since I opened it), then I think it is fair if you close it with 'works for me'
Thanks for the reply, that's quite appreciated. Adjusting to worksforme.