| Summary: | "Draw window borders for maximized windows" setting causes titlebar buttons' click zones to shrink | ||
|---|---|---|---|
| Product: | [Plasma] Breeze | Reporter: | Nate Graham <nate> |
| Component: | window decoration | Assignee: | Hugo Pereira Da Costa <hugo.pereira.da.costa> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | hugo.pereira.da.costa |
| Priority: | NOR | ||
| Version First Reported In: | 5.11.4 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
xprop on the screen's top-right-most pixel when Firefox is maximized
xwininfo on the screen's top-right-most pixel when Firefox is maximized kwin support information Screen recording of the issue Problem occurs when "Draw window borders for maximized windows" is checked The issue with borders turned on |
||
|
Description
Nate Graham
2017-12-07 17:06:04 UTC
Please use xprop and xwininfo on the top right corner. It should print the window which takes the click. Created attachment 109237 [details]
xprop on the screen's top-right-most pixel when Firefox is maximized
Created attachment 109238 [details]
xwininfo on the screen's top-right-most pixel when Firefox is maximized
Attached. The correct window gets the click, it's just that the click doesn't trigger the right-most titlebar button (in this case the close button) the way it used to.
I'll mention that this issue reproduces on X11 and also Wayland. Please provide output of qdbus org.kde.KWin /KWin supportInformation Created attachment 109244 [details]
kwin support information
I'm sorry, but I'm also out of ideas. The only idea I have is that somehow your input events are of by a pixel. That's something you could check with xev or KWin debug console on Wayland. Created attachment 109246 [details]
Screen recording of the issue
Come to think of it, it's actually not a one-pixel problem; there's a rather large dead zone. I'm uploading a screen recording that shows the issue.
Also, this doesn't reproduce with a new user account. Seems unlike to be an input issue.
I'm using a 48-pt cursor, but it reproduces using the standard cursor size.
Do you have touch screen edges activated? No. No. Created attachment 109280 [details]
Problem occurs when "Draw window borders for maximized windows" is checked
Found the issue. you can perfectly reproduce it by turning on System Settings > Application Style > Window Decorations > Breeze > Configure > "Draw window borders for maximized windows". With that setting checked, the click zone for the right-most button seems to shrink. It isn't just that the border relocates the click zone; the click zone actually shrinks. You can see this by changing your window borders to No Borders; the titlebar buttons don't move, but the click zone shrinks. I'm attaching a video that shows the exact issue.
Also it doesn't make sense to have this option even available with No Borders (there are no borders to draw!), but that's a separate issue.
Created attachment 109281 [details]
The issue with borders turned on
Video showing the issue with window borders set to something other than No Borders
Not a bug, sorry. (and the title is wrong). When "draw Window borders for maximized windows" is selected, there is no more differences (from the deco point of view) between a maximized and a not maximized window. And the buttons have the _same_ hit area in both cases. This so that one can resize the window from its borders. only when the option is unchecked does a maximized window behave differently from an unmaximized one: you cannot resize the window from its borders, and the hit area for the buttons is _expanded_. I think this is the natural behavior that one would expect from the deco (and that all decorations behave the same). Closing as invalid. (As for: there should be now option when "no border" is selected, the point is that in fact, even in the "no border" case, the 'top' border, from which you can resize the window, is always drawn.) Thanks Hugo. Could we consider changing the string to indicate that it will make the window resizable while maximized? That might help explain the purpose of the feature (i.e *why* you might want the window borders to be shown when the window is maximized). How about this: "Draw window borders and allow resizing for maximized windows" If that (or something else) seems reasonable, I'd be happy to submit a patch for it. Git commit bdf85c5c32f6a0eb3ea5f56b8008f4ed16fba424 by Nathaniel Graham.
Committed on 12/12/2017 at 13:23.
Pushed by ngraham into branch 'master'.
Make it obvious what "Display window borders for maximized windows" is for
Summary:
Change "Display window borders for maximized windows" to "Allow resizing maximized windows from window esges"
This makes it obvious what the purpose of the feature is, and why one would want to turn it on.
Test Plan:
Tested in KDE Neon. feature still works, and only the text is changed. Before:
{F5540181}
After:
{F5542554}
Reviewers: hpereiradacosta, #breeze, #vdg
Reviewed By: hpereiradacosta
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D9284
M +1 -1 kdecoration/config/ui/breezeconfigurationui.ui
https://commits.kde.org/breeze/bdf85c5c32f6a0eb3ea5f56b8008f4ed16fba424
|