Version: (using KDE 4.4.0) Installed from: Unspecified Linux Often a window will be in the upper-right corner of the screen, yet not maximized. In this incident, Plasma will close the window _behind_ the open window. Steps to reproduce: 1) Open a Dolphin window maximized. 2) Open a Konqueror window not-maximized. 3) Drag the Konqueror window's titlebar to the far right edge of the screen. The window should resize to half the screen. 4) Slam the mouse to the upper right corner of the screen and click. The Dolphin window in the background gets closed, not the Konqueror window. There are other common situations in which a window will be in a similar position. For instance, for some users Mozilla apps (Firefox/Thunderbird) always open in a not-quite maximized state. Or maybe the user simply dragged a window there. I suggest that if the window edge is less than N pixels from the screen corner, that the close operation be performed on it. A good value for N might be about half the Cashew radius.
Related issue: https://bugs.kde.org/show_bug.cgi?id=228420
window management is kwin, not plasma.
And how exactly is that supposed to work? We magically know what the user wants to click and pass the click to another window than the one which get's clicked? I think the only possible solution is that each decoration has to be changed to remove round corners when the window is at the screen edge. Even if we do that for decorations shipped with kwin, we cannot enforce it for 3rd party decorations, so I don't think it's a working solution.
Martin, please bear with me as I am not a programmer. What passes those clicks to the windows? Can that component be aware of the presence of a window near the corner?
(In reply to comment #4) > Can that component be aware of the presence of a window near the corner? Yes it could, but it is unbearable. First of all we would have to test for each click if it is near the border. Then we would have to test if there is another window close to the click and above the window which would get the click. Appearently we only want to do that if the window below is maximized and would be closed by the click. The maximized part we can know, the getting closed we cannot know. Sorry that would not work. The chances to get it wrong are way higher than to get it right. Imagine you want to close the window below, you explicitly click on it and it closes a different window. That's not what you expect. We just cannot read the user's mind ;-)
That sounds bad! There must be some solution. Maybe a transparent window (the user doesn't even know it's there) that is always occupying the upper-right 3x3 pixels of the screen, to catch and deal with these events in a good manner? > Imagine you want to close the window below, you > explicitly click on it and it closes a different window. This is why I suggested to restrict that feature to just a few pixels from the corner, as in those cases there is zero chance that the user will want to click the window below as he cannot see it. As it currently stands, the current behaviour already closes the wrong window from the user's perspective.
first off: the solution is for decorations to test whether the maximized window is either upmost in stack or the windows above are "far away" from the resp. corner - otherwise skip the "close on outer corner click" feature. this is the only non-destructive behaviour, what's crucial, given this request is about heuristics. now, on the original request (and time for diminished serious flaming :) there is no solution, martin pointed it - we dramatically lack a brain interface to read the users mind. there's even no guarantee that the close button is in the "upper right corner" of the window and also the user might really want to close the window behind. if you keep an (maybe additional) panel on the top you're doomed as well decorations _can_ unshape corners at screen borders (they could even restrict this to the corner that -in case any at all- has the close button) and the "close on extreme corner pixel" feature is a decoration this as well anyway so this really has to been solved by each deco, BUT: i'd rather do not - the behaviour becomes somewhat random. just assume the window is not really snapped to the corner, yet the user might _assume_ this (esp. if it's restricted to "just a few pixels", whats not quite precise ;-), concluding "i can safely click the screen corner" and then kiss all his precious data bye-bye :) aside this, even the solution for maximized windows imho is problematic, because a) maximized windows are plain wrong ;-P b) it's actually an unforseen behaviour (as long as the close button does not visually reflect the pseudo hovering) and esp. the close button is somewhat critical (an xterm with vim will just close, no matter how much you just hacked there... :\ ) So, solution: don't use maximized windows (except maybe on netbooks) =)
> So, solution: don't use maximized windowso, solution: don't use maximized windows Or don't use window decorations with rounded corners ;)
> Or don't use window decorations with rounded corners ;) Actually, that does sound like the solution. I did not realize that this is dependant upon windows decoration. If windows decoration with rounded corners were a visual effect (that is, the corners exist but are transparent) then the issue would be solved. Is that possible: to included the corners for purposes of identifying clicks?
(In reply to comment #9) > I did not realize that this is dependant upon windows decoration. I mentioned that in comment #3 > If windows decoration with rounded corners > were a visual effect (that is, the corners exist but are transparent) then the > issue would be solved. Is that possible: to included the corners for purposes > of identifying clicks? it is possible iff desktop effects are used. Without desktop effects there would be a random clolor pixel giving a bad visual impression. So to summarize: no, in general it is not possible
> it is possible iff desktop effects are used Then please do so at least for the composting users. Thanks.
*** Bug 161407 has been marked as a duplicate of this bug. ***
At least with Oxygen as of 4.8 the behavior described in comment #0 is no longer reproducable. Slamming the mouse cursor into the upper right corner ends in window resize cursor and the click does not close a maximized window underneath.
*** Bug 310669 has been marked as a duplicate of this bug. ***
> At least with Oxygen as of 4.8 the behavior described in comment #0 is no longer reproducable. > Slamming the mouse cursor into the upper right corner ends in window resize cursor and the click > does not close a maximized window underneath. As is apparent in bug #310669, Oxygen as of KDE 4.9.2 suffers from this issue. So whatever fix made its way into 4.8, was rendered invalid in 4.9. Additionally, the issue was tested in Plastik which also suffers this issue.
As of composited mode, oxygen has a rectangular input here (git master) and while does not close the upper window, but enters resize mode (hinted by cursor) does NOT cause a below window to be closed. Plastik is rectangular in upcoming 4.10 QML implementation (only) Passing to Hugo for pot. differences in 4.9 and 4.10, but would not recall any.
@Thomas, yes, was always the case with compositing on as far as I can remember Is not the case in non compositing mode, since the corners are rendered using a mask (because of the lack of transparency), and because (as far as I know), the rendering mask is also used for input. In fact, if both could be decoupled, that would solve the issue. (rendering vs input). Any thought on that ?
@Dotan on bug bug #310669, it is not clear (to me) in the screenshots. Are you, or are you not using desktop effects (compositing) in these screenshots ?
Desktop effects (composting) is in fact enabled on my system.
... can't reproduce, then. I'll checkout with 4.9 will keep you posted
So ... with 4.9 + compositing ON, I cannot reproduce either, and was not expecting to. Input window is square (you can even check for windows not in the corner). This is because no mask is set in the code, and besides, the actual window also extends to include the shadows ... so I'm confused. I've always been able to reproduce this bug only when compositing is OFF ...
@Thomas do you think we can use "extended window borders", (which is working in non-compositing mode) so that the (masked) corners are also used for resize ? That would fix the non compositing case. (I'm actually testing this now) If yes, do we agree to implement that ? (that is: Square input window - always - ) even if this appears rounded ? That would fix the issue. That would also change the behavior for all windows, but behavior only concerns ~ 4 pixels in each corner, and you have the right feedback from the mouse cursor. What do you guys think ?
Git commit 3e9b116947b94bc305255436e0055b618cbb5fc2 by Hugo Pereira Da Costa. Committed on 26/11/2012 at 10:55. Pushed by hpereiradacosta into branch 'master'. Extend window border to the masked rounded corners in non compositing mode M +29 -11 kwin/clients/oxygen/oxygenclient.cpp http://commits.kde.org/kde-workspace/3e9b116947b94bc305255436e0055b618cbb5fc2
Commit in comment above fixes it in the non-compositing mode. Since I can't reproduce the issue in compositing mode with trunk (== KDE 4.10), I consider this bug as fixed. It is still a mystery though, that Dotan could trigger the issue in compositing mode with KDE 4.9 whereas I could not. Feel free to reoppen if the issue persists. (with oxygen)
To me it looked like a non-composited setup, but only: qdbus org.kde.kwin /KWin supportInformation will tell. Note: there might be a difference between what is configured and what is really used
@Martin Why re-oppen ?
... also: notes about comments #22 and #23 In fact this change (enabling resize from the masked round corners) is needed no matter what. When extended-window borders is enabled you get this extra three pixels on the sides to resize the window. If you don't include the corners (as is done with the commit), you end up with a weird situation in the corners where your can: resize - not-resize - resize again. Not acceptable :)
re-closing, assuming the re-oppening in comment #25 is a mistake (there is no mention there why the bug should be re-oppened.
Thanks. When 4.10 comes out I will retest on my current ~/.kde and on a fresh profile. If I find a discrepancy then I will try to narrow down the ~/.kde and post a zip that reproduces the issue. Have a great week!
Thanks Dotan, waiting for your feedback
ah yes, that was me being to stupid to use bugzilla, sorry about that
*** Bug 161107 has been marked as a duplicate of this bug. ***
sorry for the delay. @hugo - "yes" ;-) however, taking a close look at the shot in the dupe, the problem there is completely unrelated since the window is not only not maximized but also does not reach the right edge, thus upper right corner, thus does not work w/ compositing either. what dotan wants is some more heuristics about which window might be meant to close and a screencorner to close "that" window on click, ie. a brain interface and feature in active screenedges. since my brain interface does still not work correctly (ask my poor hamster about the consequences of using it...) i would rather not add such feature to the screen edges (where there also may be an autohiding panel) and repeat that destructive operations should happen through dedicated and hinting interfaces (ie. one close button per window) and not by some invisible pixel and a short pray regarding its consequences ... the input window should however at least for their width prevent closing the window beneath - so lets wait for the bug report with the 4px offset shot attached ... :-\
> however, taking a close look at the shot in the dupe, the problem there is completely unrelated since the window is not only not maximized but also does not reach the right edge, thus upper right corner, thus does not work w/ compositing either. ... confused about that: if the window is few pixels away from border, yes, the mentioned issue is not only about corner, but also sides. and yes, it would also affect with-compositing. But that's unrelated to the fact that oxygen has round corner (oxygen does have *square* input, now both in compositing and non-compositing mode). Now: extended window borders would actually also fix this: if you have few invisible pixels on all sides that do belong to the window, that would also fix the issue, right ? In fact I personally would find it more an annoyance than anything else (these few pixels belonging the the 'wrong' window. ... so that in oxygen, I only enabled 'extended window borders' for the sides that explicitely have no decoration (namely if you chose either 'no-side borders" or "no borders" for the decoration frame width ... In any case, I agree that there is nothing more that I would be ready to implement, than the use of "square" input window, disregarded from whether the corners are round or not ...
simple explanation: the dupe is none =) this bug was originally however about non max'd wins in the upper right corner and my vote on the non-dupe finishes by "...and if hell freezes over" >) plus i'd actually leave the entire titlebar out of the extended region in bespin (current code is poc level since one needed unpushed git patches back then)
> what dotan wants is some more heuristics about which window might be meant to close > and a screencorner to close "that" window on click, ie. a brain interface and feature in > active screenedges. A brain interface? How derisive! As mentioned in the dupe: "When a window's top border is against the top of the screen and its right border is against the right side of the screen, the user expects that he can slam the mouse pointer into the upper-right corner and click to close the window." When the Ocular window opened, I had no idea that it was not maximized, it superficially looks maximized. I was very surprised when the window _behind_ it closed. In fact, if the window's top border is against the top of the screen and its right border is against the right side of the screen, it is completely unreasonable to expect that the user who clicks in the upper right corner to expect the window behind the current window to be closed. How is the user supposed to know that the window decoration has a one-pixel hole right in the corner, where Fitt's law dictates would be the obvious place to click to close the window? The problem is a technical one of implementing the expected behaviour despite the fact that the window has a decorative hole right where the user expects to be able to click. There is no question of what the user intended when he clicks the upper right corner of a window which has its top edge against the top of the monitor and its right edge against the right of the monitor, especially considering that Fitt's law dictates that as the most likely place to click.
> In any case, I agree that there is nothing more that I would be ready to implement, than the use of > "square" input window, disregarded from whether the corners are round or not ... I agree: making the input square, even if visually there is a hole in the corner, is the correct solution. Thank you!
(In reply to comment #36) > "When a window's top border is against the top of the screen and its right > border is against the right side of the screen, What is *not* the case in the screenshot. Period. And that screenshot also explains why it fails with compositing. Period once more. > When the Ocular window opened, I had no idea that it was not maximized, it > superficially looks maximized. There's a hint in the maximize button. And also a 1px gap on the right and the bottom - in both shots. > In fact, if the window's top border is against the top of the screen and its > right border is against the right side of the screen, What is *not* the case in the screenshot. Once again. We are not discussing /that/ case.
Thomas, the screen shot has a dimension of 1682x1052. The ususal resolution is 1680x1050, so it looks like there are two "random" pixels, that should not be part of the screen shot. In other words, the window is in fact touching the upper and right edges.
>> "When a window's top border is against the top of the screen and its right >> border is against the right side of the screen, > What is *not* the case in the screenshot. Period. >And that screenshot also explains why it fails with compositing. Period once more. To test and set things up after being bitten by the issue, the Ocular window that you see was created by dragging the window to the right side of the screen such that Kwin will resize it to half a screen width and full height. I then right-clicked the Maximize button to maximize horizontally. I don't know what those red pixels are on the side, but they are spurious and not a part of the screenshot. Perhaps that is some Ksnapshot issue, I don't know. >> When the Ocular window opened, I had no idea that it was not maximized, it >> superficially looks maximized. > There's a hint in the maximize button. And also a 1px gap on the right and the bottom - in both shots. The only hint is in the maximize button, the gap is spurious and not part of the screenshot. And though I do now know to check the maximize button for the window state because I am familiar with the issue, I still believe that a window which is aligned to the upper and right edges of the screen should be closed when the upper-right corner is clicked. If there is contention about the window closing I am willing to submit to contention on that. But certainly, don't close the window behind it! That is the real crux. >> In fact, if the window's top border is against the top of the screen and its >> right border is against the right side of the screen, > What is *not* the case in the screenshot. Once again. We are not discussing /that/ case. That is exactly the case that is under discussion. I submit that a 1px gap from the window to the screen edges is a technical reason to close the window behind, even though that is clearly not the user intention. Note that despite the spurious errors in the screenshot, that was not the case submitted by me.
(In reply to comment #40) > I then right-clicked the Maximize button to maximize horizontally. I don't > know what those red pixels are on the side, but they are spurious and not a > part of the screenshot. Perhaps that is some Ksnapshot issue, I don't know. What's the output of "xrandr -q"? I've never seen ksnapshot overscanning. What's the output of "xwininfo -frame -shape" when clicking on such window (only the output of shape extents is relevant, "-frame" parameter is important.
- neptune:~$ xrandr -q Screen 0: minimum 320 x 200, current 1682 x 1052, maximum 8192 x 8192 VGA-0 connected (normal left inverted right x axis y axis) 1680x1050 59.9 + 1600x1200 60.0 1680x945 60.0 1400x1050 60.0 1600x900 60.0 1280x1024 75.0 60.0 1440x900 75.0 59.9 1280x960 60.0 1366x768 60.0 1360x768 60.0 1280x800 74.9 59.8 1152x864 75.0 1280x768 74.9 59.9 1024x768 75.1 70.1 60.0 1024x576 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 848x480 60.0 640x480 72.8 75.0 66.7 60.0 720x400 70.1 DVI-0 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 473mm x 296mm 1680x1050 59.9*+ 1600x1200 60.0 1680x945 60.0 1400x1050 59.9 1600x900 60.0 1280x1024 75.0 60.0 1440x900 75.0 59.9 1280x960 60.0 1366x768 60.0 1360x768 60.0 1280x800 74.9 59.9 1152x864 75.0 1280x768 74.9 60.0 1024x768 75.1 70.1 60.0 1024x576 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 848x480 60.0 640x480 72.8 75.0 66.7 60.0 720x400 70.1 - neptune:~$ xwininfo -frame -shape xwininfo: Please select the window about which you would like information by clicking the mouse in that window. xwininfo: Window id: 0x2201d90 (has no name) Absolute upper-left X: 65 Absolute upper-left Y: 0 Relative upper-left X: 65 Relative upper-left Y: 0 Width: 1615 Height: 1050 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +65+0 -2+0 -2-2 +65-2 -geometry 1615x1050-2+0 Window shape extents: 1615x1050+0+0 No border shape defined - neptune:~$ The window was a Konqueror window dragged to the right side of the screen to half-screen it, then I right-clicked the Maximize button in order to extend the window horizontally. Note that I do have a vertical panel along the left side of the screen, this will account for the corner being 65 pixels away from the left edge. The monitor is connected via DVI but upon every boot the display seems interpolated just a bit and I have to open System Settings, disable the VGA output, and then Apply. Only then does the display look as it should. Perhaps this is related, as it can been seen that the VGA output (not the output going to my DVI connection) is off by the same size as the screenshots were off. It does seem reasonable that this is the my clicks were not being captured by the correct window. Might it be that the component resizing the window is (correctly) resizing to the DVI monitor's screen size, but that the component capturing the clicks is (incorrectly) looking at the non-existent VGA monitor's screen size? I stress that VGA output is disabled, that is the first thing that I do after every boot in order to correct the screen presentation issue.
(In reply to comment #42) > Screen 0: minimum 320 x 200, current 1682 x 1052, maximum 8192 x 8192 You've see that. > - neptune:~$ xwininfo -frame -shape > Window shape extents: 1615x1050+0+0 This means the window *is* shaped, what either means you're not using oxygen but a permanently shaping deco at this moment or oxygen shapes because compositing is not active or it miscalculates that compositing is not active. Either way, it explains alone why the clicks go through. Now reg. the screens. As you mentioned yourself, there's a problem with your screen setup and the interpolation hints that some scale factor is active. If you cannot see those additional pixels, you've have them on another "screen" rather than scaled or panned, but that's hard to say and not explained by the xrandr output. please run: xrandr --output VGA-0 --off xrandr --verbose --output DVI-0 --scale 1x1 --mode 1680x1050 --pos 0x0 and re-check xrandr -q ~/.kde/share/config/krandrrc might contain the reason for the bogus initial setup, in doubt, check what happens if you reset defaults in "kcmshell4 randr" (the save as default button shows a popup and allows to reset custom settings) > Might it be that the component resizing the window is (correctly) resizing > to the DVI monitor's screen size, but that the component capturing the > clicks is (incorrectly) looking at the non-existent VGA monitor's screen > size? Maximizing happens "per panel", but the pointer can generally go across the entire X11 screen (ie. the upper right corner is +0+1682 in your case) and window moving is constrained resp. snapped to that geometry as well. In order to have things wor as expected you need to get rid of those 2 extra pixels, but as mentioned above, the window you checked /was/ shaped at that time (not maximized or not (perceived) composited) I stress that VGA output is disabled, that is the first thing that I > do after every boot in order to correct the screen presentation issue.
This is right after boot, before disabling the VGA output in System Settings. Of course, the first command took care of the VGA disable, but I figured it may be important to try this with the system as it is on boot. - neptune:~$ xrandr --output VGA-0 --off - neptune:~$ xrandr --verbose --output DVI-0 --scale 1x1 --mode 1680x1050 --pos 0x0 crtc 1: 1680x1050 59.9 +0+0 "DVI-0" - neptune:~$ xrandr -q Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 8192 x 8192 VGA-0 connected (normal left inverted right x axis y axis) 1680x1050 59.9 + 1600x1200 60.0 1680x945 60.0 1400x1050 60.0 1600x900 60.0 1280x1024 75.0 60.0 1440x900 75.0 59.9 1280x960 60.0 1366x768 60.0 1360x768 60.0 1280x800 74.9 59.8 1152x864 75.0 1280x768 74.9 59.9 1024x768 75.1 70.1 60.0 1024x576 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 848x480 60.0 640x480 72.8 75.0 66.7 60.0 720x400 70.1 DVI-0 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 473mm x 296mm 1680x1050 59.9*+ 1600x1200 60.0 1680x945 60.0 1400x1050 59.9 1600x900 60.0 1280x1024 75.0 60.0 1440x900 75.0 59.9 1280x960 60.0 1366x768 60.0 1360x768 60.0 1280x800 74.9 59.9 1152x864 75.0 1280x768 74.9 60.0 1024x768 75.1 70.1 60.0 1024x576 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 848x480 60.0 640x480 72.8 75.0 66.7 60.0 720x400 70.1 - neptune:~$ In this configuration, with a non-maximized window whose upper edge is against the top edge of the screen and whose right edge is against the right edge of the screen on KDE 4.9: Oxygen: Clicking in the upper-right corner gives a resize handle on the top window. Plastic: Closes maximized window behind the top window (not the expected top window). I will test in KDE 4.10 with Hugo's changes and report back in some time. Thank you!