| Summary: | Clickable area to resize windows is significantly smaller on top of windows | ||
|---|---|---|---|
| Product: | [Plasma] Breeze | Reporter: | Riccardo Robecchi <sephiroth_pk> |
| Component: | window decoration | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | ASSIGNED --- | ||
| Severity: | normal | CC: | el, john, kwin-bugs-null, nate, sulmpx60, uhhadd |
| Priority: | NOR | Keywords: | accessibility |
| Version First Reported In: | 6.3.5 | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Resize arrow triggering at different distances from the top border vs. other borders
Resize arrow triggering after MR 582 (add top margin) |
||
|
Description
Riccardo Robecchi
2025-05-14 17:05:42 UTC
Is this on X11, or Wayland, or both? What decoration theme do you use? I've tested this on X11. The decoration theme is Breeze. Can you try on Wayland too? So, I've tried with other decorations and it's the same with all of them. It also happens on Wayland on a different computer. Thanks for testing! I can reproduce this behavior on my Fedora KDE 42 device, with Breeze window decorations in a Wayland session. At first, I wondered if this was somehow intentional behavior, to try to avoid the top edge of one window interfering with access to an adjacent window's controls, or with a top-aligned panel? I don't recall seeing anything related to that going into effect in 6.3.5, though. Thanks! Created attachment 181484 [details]
Resize arrow triggering at different distances from the top border vs. other borders
I moved this bug report to Breeze because Kwin has nothing to do with it. Breeze disables the top resize border https://invent.kde.org/plasma/breeze/-/blob/7f9ec509a3ef8a53ba265f32b39c8cc832fea787/kdecoration/breezedecoration.cpp#L482 Not sure if it's actually a bug though. I assume that breeze doesn't set that resize border because there's some space reserved by the decoration on top. (In reply to Vlad Zahorodnii from comment #9) > I moved this bug report to Breeze because Kwin has nothing to do with it. > Breeze disables the top resize border > https://invent.kde.org/plasma/breeze/-/blob/ > 7f9ec509a3ef8a53ba265f32b39c8cc832fea787/kdecoration/breezedecoration. > cpp#L482 It's not just Breeze, though. Every single window decoration I have tried does this: Oxygen, Arc, Plastik, Qogir, all exhibit the same behaviour. Why is the outside-of-the-window resize clickable area left up to the window anyway? Couldn't the compositor pick up clicks in that area, and e.g. clamp them to the window area to make sure the resize works no matter if the theme is aware of "invisible outside areas for resize" or not? A possibly relevant merge request was started @ https://invent.kde.org/plasma/breeze/-/merge_requests/582 I added the same margin at the top and did not notice any problems during testing. https://invent.kde.org/plasma/breeze/-/merge_requests/582 According to the history of GIT, I found that this functionality with 'resize' borders seems to have been added in 2014 (https://invent.kde.org/plasma/breeze/-/commit/e88463c09c0d042ed043afa1470fcb6bcd0664b4) But there is no explanation why the top margin is zero. There may have been some problems before, but I haven't found any problems now. I've tested this change on Breeze Qt6 + KDE 6, Breeze Qt5 + KDE 5, X11, and Wayland. Created attachment 189438 [details]
Resize arrow triggering after MR 582 (add top margin)
Since that's a breeze commit, I'm guessing this isn't some compositor level fix to make sure this works no matter the theme? (In reply to Ellie from comment #16) > Since that's a breeze commit, I'm guessing this isn't some compositor level > fix to make sure this works no matter the theme? That's right, this MR 582 adds a top margin only for Breeze decoration by adding a top border in 'resizeOnlyBorders'. But the 'resizeOnlyBorders' feature itself comes from the kwin compositor. It's just that at the level of the decoration theme we can control the width of these invisible borders, and transfer the width values of the invisible borders for all four sides to kdecoration -> kwin. I also think the idea here is that when we have the visible window borders enabled, usually the invisible borders ('resizeOnlyBorders') are not used, and the window can only be resized by dragging these visible window frames. It is probably for these reasons that invisible borders are managed at the decoration theme level, rather than globally at the compositor level. So, in my opinion, it would be wrong to hardcode these borders at the kwin level. |