Bug 178066

out of curiosity, how do you expect unhide to work if you over-shoot the screen edge with the mouse?

we might need to do something odd with such panels to compensate for the mouse-can-go-past-it problem ... 

(In reply to comment #1)
> out of curiosity, how do you expect unhide to work if you over-shoot the screen
> edge with the mouse?
yes sounds difficult. Perhaps it's possible to interpret mouse coords below the screen as the lowest coordinate of the screen.
> 
> we might need to do something odd with such panels to compensate for the
> mouse-can-go-past-it problem ... 
Multiscreen Voodoo - I love it

*** Bug 180431 has been marked as a duplicate of this bug. ***

*** Bug 180867 has been marked as a duplicate of this bug. ***

I can confirm this as well in the 4.2 release.

Using an Intel GMA 965 with xrandr

1280x800 on left,  1280x1024 to the right

I have this problem as well.  There are two issues that appear to have the same cause but make finding a workable solution a bit harder.  

One situation is the one described in the original post.  That is, with twinview (and perhaps xinerama as well) the actual desktop area is the combined size of the two screens.  This means that no matter what you do, you have to have it set up so you can go above or below the edge of the smaller screen (or both), there is no way to avoid it.  The solution would be to have it so the "hit target" (I am not sure if that is the right name) for the panel is not the edge of the screen like it is now, but the edge of the screen and any point past the edge (so if you go above the screen, that is still considered part of the hit target).  

The problem arises when you try to put a panel between screens.  You have the same issue, the hit target is unreachable.  But if you do what I suggested above, that means that whenever you go onto the other screen the panel will show itself and remain shown until you go back on to the first screen.  

This is not actually that bad of a solution, it will never get in the way of what you are doing because it will alway show on the screen that the mouse is not on, but it is a bit of overkill.  

I see two solution, which really depend on what the API provides.  If you are able to tell the screen layout, that is tell which areas of the desktop are not really there on the screen (which you seem to be able to since plasma resizes the desktop correctly), then I would suggest making all invisible areas be considered part of the hit target for an auto-hiding panel.  If there is an invisible area between two screens, you could divide it in half, divide it proportionally to that dimension of the two screens, or just have it shared between the two screens.

As for the area between two touching screens, perhaps a solution would be to extend the hit target by 5 or 10 pixels beyond the edge of the screen on to the next screen.  I think that is a reasonably good compromise, it would make a panel there usable without making it always visible when you are on the opposite screen.  That thin area is also not used all that often by programs (except scroll bars) and it should never interfere with what you are doing because the panel will only show when you move your mouse on the screen opposite the panel.

If you can't tell the screen layout, that is you cannot tell which desktop borders are between two screens and which aren't, then I would use the second solution on all desktop borders.  That is, the hit target for an auto-hiding panel extends 5 or 10 pixels beyond the edge of any desktop. 

I have just commited a little app to prevent the mouse-pointer to enter these "dark areas" in multiscreen-setups.
You can find it in playground/utils/noenter. It should compile on 4.2 as well as trunk.

(In reply to comment #7)
> I have just commited a little app to prevent the mouse-pointer to enter these
> "dark areas" in multiscreen-setups.
> You can find it in playground/utils/noenter. It should compile on 4.2 as well
> as trunk.

Compiles fine, runs fine.  It certainly doesn't let the mouse go past the bottom of the screen.

However, the plasma bar exhibits new behavior.  It will "jump" up and down for a while when you place your mouse at the hotspot.  Sometimes, it will not appear at all.  I've noticed that a slight movement of the mouse from the very bottom of the screen upwards just a bit will jog it up and down, but leaving the mouse at the very bottom of the screen typically does not make the bar appear.

Thanks for investigating this.

SVN commit 938069 by asommer:

Use mouse-poll-timer for auto-hide, even if no popup is open. This makes the panel stay, if the pointer only leaves for a few ms.
Correctly resize new panels to the screen they are created on.
BUG:178066

 M  +12 -15    panelview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=938069

SVN commit 942883 by asommer:

Backport 937003 and 938069.

- update struts when the framebuffer is resized
- create PanelView instances only when the screen they are for is active
- destroy PanelViews when their screen is deactivated

Use mouse-poll-timer for auto-hide, even if no popup is open. This makes the 
panel stay, if the pointer only leaves for a few ms.
Correctly resize new panels to the screen they are created on.

BUG:181441
BUG:185471
BUG:179131
BUG:178066

 M  +14 -0     desktopcorona.cpp  
 M  +34 -21    panelview.cpp  
 M  +23 -15    plasmaapp.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=942883

I still have this problem in KDE 4.3 beta 2.

This problem is still present for me in KDE 4.3 RC 1.  It is essentially impossible for me to unhide panels at the top of my smaller screen.

Have you tried the app mentioned in comment #7? Does this help? If so we might polish it a bit and make it more easily available...
:-)

That seems to work.  Thanks!

Was the application noenter ever included in KDE SC?  My mouse is still able to go into blank areas in SC 4.5 RC3

Can someone please re-open this bug?  It is definitely not fixed.  Unhiding panels is possible now, but still really tricky.  And the application that could fix it, noenter, no longer builds since it depends on kephal which is not available.  So we are still left with no good solution to this problem.

there are no plans to support autohide panels between screens better than they are now; there just isn't any useful solution that doesn't bring significant drawbacks with it.

for panels on screens that do not abut the desktop, this really feels like an x11 problem, not something we should try and work around in plasma-desktop. why the mouse is allowed into those non-visible areas (other than the obvious "it was the easiest thing to implement") is beyond me.

the approach in noenter (which still build, btw; you just need the kephal headers from kdebase/workspace/libs/kephal) is a bit on the "ew, that's unfortunate" side -> it creates a whole QWidget and then uses XTest to move the mouse out. looking at the implementation, it doesn't seem to handle situations such as a three monitor setup with the middle one being shorter than the other two? in any case, finding the holes is pretty simple using a QRegion and subtracting each screen from the desktop rect.

the question is what to do with that. it may make the most sense to roll this into the edge-of-screen-triggers app that we talked about last year, Martin?

The issue isn't so much panels between screens, the issue is panels at the edge of an inaccessible area of the screen.  The approach that seems to make sense to me is to show the panel if the mouse at the edge of the screen where the panel is, or beyond the edge of the screen where the panel as, so long as the mouse isn't inside another screen.  In other words, keep the same length for the panel "hit area", but extend it to infinity off the edge of the screen (or until it runs into another screen).

> the question is what to do with that. it may make the most sense to roll
> this into the edge-of-screen-triggers app that we talked about last
> year, Martin?
I am against working around either in kwin or in plasma. This needs to be fixed in a different layer. There are just too many corner cases which make it IMHO impossible to guarantee a working solution.

Do you have an example of a situation that my proposal wouldn't be able to handle?

> Do you have an example of a situation that my proposal wouldn't be able to
> handle?
Three screens: left, right top, right bottom. Right screen aligned to left one 
at top and bottom edges. Between the two right screens there's a gap (to make 
more fun there's also a gab between left and right bottom screen). Now add an 
autohide panel to the bottom of the right top screen and an autohide panel to 
the top of the bottom right screen. Question: To which screen does the mouse 
belong in the free space between left and bottom and top screen?

Yes with three and more screens we can easily construct all kinds of setups 
where it fails.

"To which screen does the mouse belong in the free space between left and bottom and top screen?"

Both of them.  It would unhide both panels in this situation.