| Summary: | KWin should default to preventing configure (and map) requests that move the client off any screen and only allow by rule | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Damian Nowak <oferty> |
| Component: | xrandr | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | wishlist | CC: | kde.org, postix |
| Priority: | NOR | Flags: | thomas.luebking:
Decision-Required+
|
| Version First Reported In: | 4.11.8 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Damian Nowak
2014-04-11 13:06:24 UTC
I assume part of the problem is that the area around (0,0) is in a non-visible space. Overall the X-Screen is the bounding rect of your setup, so an application might happily place their windows in such an area without further checking whether it's valid. Of course KWin should apply some force checking, but well four screens is difficult to test ;-) As a workaround you can use window rules to force a position on your window. I don't know the code, but theoretically Kwin can get all the coordinates from xrandr: DisplayPort-0 connected 1920x1200+1920+0 HDMI-0 connected primary 1920x1200+1920+1200 DVI-0 connected 2560x1440+3840+960 DVI-1 connected 1920x1200+0+1200 If the application puts itself into a wrong coordinate, KWin could react and move it somwhere to "primary" screen (or the screen where the cursor is on). We'd need to know whether the client demands thatr position or moves itself after mapping.
Please run
kcmshell4 kwinrules
setup a new rule for the window and in "Size & Position" set "Ignore requested size & position" to yes and try "apply initially" first, then "force" and report which setting is required to move the window in sight.
If you can't "detect" the window (for lacking access) you can just create a "blind" rule (no detection, will match every window; you'll get a warning) for this test.
Thanks.
Thanks Thomas. "Apply initially" never works, whereas "Force" fixes all the problems. I wasn't able to catch Adobe Reader, so I created a blind rule. These fields "Window class" or "Window title" never wanted to work for me. I am OK to set a rule temporarily for Adobe Reader - however, only a blind rule seems to work for me. I can't use it every day since it breaks other stuff (e.g. positioning of ALT+F2 menu). I tried to use the following: - Window class - Substring Match - Adobe Reader - Window title - Substring Match - Adobe Reader Once the window is in sight, try to use the detect button (unless adobe also manages to alter the window class after mapping the window ...) To avoid krunner, only match "normal" window types. Bug is in AAR, we need to figure whether we can boldly deny "stupid" configure requests by default. Thanks, works now. I have to do the same with Skype and gns3. Hope you can code a real fix for that. Thanks. sky surprises me - shouldn't it be Qt? See eg bug #231524 - good toolkit doesn't mean nice client... This will likely be part of a "works everywhere" strategy (similar to some weird things in firefox) Iirc, there's also a bug where the client just adds an XMoveResize window to ensure the WM got it right and another one where the client assumes the request is always granted (leading to a diverging internal idea of its position - not! the tcl/tk thing) The clients will just check where they got positioned, define it "absurd" and move into a "safe" position instead (QWidget::setGeometry() ...) The idea that clients will just XMoveResizeWindow if we're to strict is my major concern in resolving this (codewise it's simple) This bug report is quite old. Can you please confirm, that the issue still persists with KDE 5.23? Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |