https://bugs.kde.org/show_bug.cgi?id=351175
--- Comment #60 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Nate Graham from comment #59)
> So to fix this in a way that makes sense, we would probably need to
> implement some kind of edge stickiness feature for screen edges between
> monitors that have hidden panels on them, as is proposed for Bug 416570. If
> we don't or can't do that, then there will remain no practical way to move
> the cursor onto the pixel that triggers the hidden panel [...]
> I think our path forward is to implement the feature requested at Bug 416570,
> and then make it always-on for edges between screens that have hidden
> panel on them.
I believe that's only partially correct... as described below:
Note that for at least some people CCed to this bug, their screen configuration
might look like this (ASCII-art best viewed with a monospace font or the spaces
will be too small horizontally and it won't align):
+----------+----+
| not here>| v |
| +----+
| >|< ^
+----------+
In words, that's a higher resolution screen to the left, with a lower
resolution screen to the right and aligned at the top, leaving an undisplayed
square to the bottom right.
The paired arrows indicate edges that should be hard-stops for the pointer as
they're bordered by only a single screen, not between screens, making them easy
to hit (Fitt's law).
Or even (basically my setup when I reported):
+----+
| v >|< v
+----+----+
^ >|< ^ |
+----+
That's two screens diagonal to each other so they only connect at a corner --
no actually shared borders so Fitt's law applies to all edges, only the corner
connecting them (which makes it easy to switch screens with the pointer, just
hit an edge that extends to the other screen and slide toward the other screen
until the pointer hits the shared corner and enters the other screen).
Regardless of what happens at the fully shared edges (like the not here edge of
the first one) where your observation applies and edge-stickiness would be
useful, there's no reason why the "internal edges" (as I called them in my bug)
that are not actually shared, so Fitt's law applies, can't have a working
autohide panel. The bug I filed was that autohide is broken on them too -- hit
that stopping-edge then move away, and a panel on them set to auto-hide did
disappear momentarily at the move-away (I'm not entirely sure this is still
the behavior as I have a different layout now, but I expect it is), but
immediately appeared again, so (except for that momentary hide and popout
again) autohide behaved as if the panel was set to permanently visible. =:^(
But it's a stopping edge that only /extends/ to a different screen, it's not
actually a shared edge that the pointer cruises over and keeps going. So
autohide really can and /should/ work, even without the sticky-shared-edge
feature described in comment #59.
So while the sticky-shared-edge idea is a rather ingenious solution (I wish I
had thought of) for actually shared edges, for stopping-edges that only extend
to a different screen and aren't actually shared, sticky-shared-edge is not
critical to having a working autohide.
--
You are receiving this mail because:
You are watching all bug changes.
