| Summary: | Electric borders are totally incompatible with autohiding panels, yet collision is possible | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Matthias Dahl <ua_bugz_kde> |
| Component: | core | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | kde.org, l.jirkovsky, rickscafe.casablanca |
| Priority: | NOR | ||
| Version: | 5.5.0 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Matthias Dahl
2015-12-11 15:19:28 UTC
can you please check the time settings in "kcmshell5 kwinscreenedges", notably the distance between activation and reactivation? Sure: Activation delay is 150ms Reactivation delay is 350ms Playing with those had not effect either (already tried that) -- and apart from that, those exact settings work fine with KWin < 5.5. :-) It would also not explain the apparent "good" left edge. - Do you have (autohiding or other) panels on either edge? - What happens if you lower activation to 0. - Is this by moving windows or by pure pointer activation - and is the other variant affected as well? (In reply to Thomas Lübking from comment #3) > - Do you have (autohiding or other) panels on either edge? Yes -- and even more interestingly, it is on the right side. ;-) Never actually suspected that one at all. Removing the panel does indeed make the problem go away. The panel is not full size and configured so that windows can go above it. And no auto hide or anything like it. It's used as an quick launcher of sorts, with icons for all my apps I use daily. > - What happens if you lower activation to 0. No change. > - Is this by moving windows or by pure pointer activation - and is the other > variant affected as well? Pure pointer activation is used here. But I just tried the by moving windows variant, and that one is _not_ affected and works just fine (w/ the panel on the right side naturally). I can reproduce the behavior and actually cannot even re-show the autohiding panel (the traditional way) - which is intended in the present code. What's not intended is the double invocation, the culprit seems to be commit 0b32e5e57ddf8184fa9c52ea67df63034a93d70c which causes a massive amount of ScreenEdges::check() even if nothing (no decoration) covers the edge area. @Martin I somehow fail to reproduce the prblem described there, can you please check whether it's still present (we had some other bugs in new screenedges which may have been the actual cause) In addition we need a policy about electric borders and autohiding panels, ie. not hide the panel if there's an electric border? *** Bug 356574 has been marked as a duplicate of this bug. *** kwin 5.6.2 here. I have a similar use case on my laptop. I use 4 virtual desktops in 2x2 on a single physical screen. All corner actions are set to none. My setup for kwin is [Windows] ElectricBorderCooldown=1050 ElectricBorderCornerRatio=0.25 ElectricBorderDelay=1000 ElectricBorderMaximize=false ElectricBorderTiling=false ElectricBorders=2 RollOverDesktops=true I pushed delay to max just to check the problem. The delay applies to mouse movements over the three clear of the four edges (left, right, top), while the mouse pointer just "falls through" the bottom edge. That is where the standard control panel is located here. It is not set to auto hide because I cannot get it back when using rolloverdesktop this way. Instead I set it so that windows can cover it. Now, in earlier kwin, I could bump the bottom edge within the delay time frame to bring the panel to foreground. That seems impossible right now as the desktop switches immediately, though sometimes it does not actually switch. There is just the animation but the desktop is the same. That might be the same as the "skipping" Matthias reported. I also tried moving windows and there is no delay, too. At the border where the panel is the movement just passes the border. This issue report is quite old. Can you please confirm, that it 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! |