https://bugs.kde.org/show_bug.cgi?id=438788
Bug ID: 438788
Summary: Non-intrusive tiling-on-demand
Product: kwin
Version: 5.21.5
Platform: Other
OS: Linux
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: general
Assignee: kwin-bugs-n...@kde.org
Reporter: pa...@web.de
Target Milestone: ---
SUMMARY
When to windows are placed directly next to each other (some time after
snapping to each other), it would be cool to have a tiling-on-demand-like
resizing of both windows at the same time
STEPS TO REPRODUCE
1. Place one window e.g. on the left side of the screen
2. Place one window on the right side of the screen
3. Move you cursor into the screen's center to get the "resize to the left or
right" cursor
4. Try to resize both windows at the same time by clicking the mouse button and
dragging to the left or the right
OBSERVED RESULT
• When holding the left mouse button: Only one window gets resized, but not the
other. Often (but not always) the other window must be resized, too, leading to
some additional work.
• When holding the middle mouse button: Nothing happens.
EXPECTED RESULT
• When holding the left mouse button: The behavior should stay as it is now, as
sometimes you only want to resize one window.
• When holding the middle mouse button: Resize both windows at the same time
implementing a stateless tiling behavior.
SOFTWARE/OS VERSIONS
Windows:
macOS:
Linux/KDE Plasma:
(available in About System)
KDE Plasma Version:
KDE Frameworks Version:
Qt Version:
ADDITIONAL INFORMATION
Although the first thought might be, that the window selection for the middle
mouse button behavior is ambiguous, I think it is a well-determined problem.
Selecting the first window is probably trivial, as the same logic can be used
as with the left mouse button.
To find the second window, loop through all windows and check whether they end
(or start, depending on being on the left or right side of the first window)
with exactly an offset of one pixel and span the same coordinate in the other
dimension (depending on resizing to the left/right or to the top/bottom). If
there are multiple windows in question, just use the top-most in the stack.
I think this would be a sane default, as the middle mouse click drag and drop
in this situation is not used as far as I know. However, it would probably make
sense to limit the new behavior to the 3 top-most options selectable in window
management → Window Behavior → Titlebar Actions → Titlebar and Frame Actions →
Middle click (Active).
Without maintaining a tiling state, the implementation should limit the
additional complexity a lot.
--
You are receiving this mail because:
You are watching all bug changes.
