Summary: | screen edges should be configurable in size and position | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Dirk Sarpe <dns_hmpf> |
Component: | core | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | wishlist | CC: | becho4, cfeck, iyvrdqxztjt, kalinq, sts, updatedb |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Bug Depends on: | |||
Bug Blocks: | 290887 |
Description
Dirk Sarpe
2009-06-14 23:49:14 UTC
*** Bug 199720 has been marked as a duplicate of this bug. *** *** Bug 198225 has been marked as a duplicate of this bug. *** *** Bug 187364 has been marked as a duplicate of this bug. *** I absolutely agree with Dirk and I think Compiz solved the problem nicely providing the posibility to trigger the effect if the mouse is on the edge and you click some button (keyboard or mouse buttons). For example, it is very convenient to rotate the desktop cube on the left and right edges with the mouse wheel. I'm currently working on a rework of the screen edge implementation (see https://git.reviewboard.kde.org/r/108513/ ) which allows me to give an update on how that affects this feature request: * screen edges become multi screen aware, this is mostly relevant for screens with different geometry * visual feedback is given before an edge is triggered. This helps a lot. But there are things which will not be implemented or made available for configuration: * corners between screens (doesn't make sense due to Fitts's Law) * configurable sizes and position for the edges as being configured in the KCM * clicking screen edges (doesn't make sense due to Fitts's Law) I'm sorry to say that this means that overall this feature request will not be implemented. Because of that I'm also changing to WONTFIX. Reading Dirk's description, the problem is that trying to invoke a corner action is very hard, because it is nearly impossible to hit that single pixel, without previously hitting the edges next to that pixel. The size of the corner should be larger (maybe the size of "start drag distance", which is configurable for similar reasons). (In reply to comment #6) > Reading Dirk's description, the problem is that trying to invoke a corner > action is very hard, because it is nearly impossible to hit that single > pixel, without previously hitting the edges next to that pixel. During developing the new screen edge implementation I had enabled the "switch desktop on edge" feature, which I normally hate. I am a heavy desktop grid and present windows user activated through corners (top left and top right) and I have never activated one of the edges next to the corner. matter of activation delay but the OP mostly seems to worry about mouse ways to the corners on huge screens / multiscreens, thus asking for in-desktop corner edges, or partial edges in general, which he can reach faster, but which do not acidentally trigger when approached to interact with the scrollbar etc. reg. christophs comment: different timeout/pushback for edges and corners sounds interesting (so you can slide into the corner, have instant corner activation and more resistive edges) On Thursday 07 February 2013 07:30:06 you wrote:
> reg. christophs comment: different timeout/pushback for edges and corners
> sounds interesting (so you can slide into the corner, have instant corner
> activation and more resistive edges)
with the new architecture that would be possible, though probably a mess to
configure.
|