Hot corners in dual-monitor setup

Bug #1080283 reported by René Vangsgaard
138
This bug affects 31 people
Affects Status Importance Assigned to Milestone
Gala
Triaged
Medium
Unassigned
Switchboard Desktop Plug
Invalid
Undecided
Unassigned

Bug Description

Hot corners do not work as I expect in dual monitor setup; the hot corners only work on the primary display. And it can of course be difficul to find the corners which are in "the middle" of the two displays.

ProblemType: Bug
DistroRelease: elementary OS 0.2
Package: elementary-desktop 1.284-0~355~precise1 [origin: LP-PPA-elementary-os-daily]
ProcVersionSignature: Ubuntu 3.2.0-33.52-generic 3.2.31
Uname: Linux 3.2.0-33-generic x86_64
ApportVersion: 2.0.1-0ubuntu15+elementary3~precise1
Architecture: amd64
CrashDB: elementary_meta
Date: Sun Nov 18 10:21:20 2012
InstallationMedia: elementary OS 0.2 "Luna" - Beta 1 amd64 (20121114)
MarkForUpload: True
SourcePackage: elementary-meta
SuspiciousXErrors:

ThirdParty: True
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
René Vangsgaard (rene-vangsgaard) wrote :
Eduard Gotwig (gotwig)
Changed in elementaryos:
status: New → Confirmed
Cody Garver (codygarver)
Changed in elementaryos:
status: Confirmed → New
affects: elementaryos → gala
tags: added: dual-monitors multimonitors
removed: amd64 apport-bug luna third-party-packages
Revision history for this message
Jaap Broekhuizen (jaapz-b) wrote :

We probably need some input from one of the designers what the desired behaviour should be.
IMO it should just make the outer corners of both screens the hotcorners, leaving the corners in the center to do nothing, as they are essentially not really corners of the extended desktop anymore.

Revision history for this message
René Vangsgaard (rene-vangsgaard) wrote :

I agree that the outer corners of the extended desktop should be hotcorners.

Revision history for this message
René Vangsgaard (rene-vangsgaard) wrote :

Do you know how we get input from the designers?

Revision history for this message
Danielle Foré (danrabbit) wrote :

What Jaap said makes sense to me, but I'm not working with multi-monitor. Assigning to UX Team and let's see of we can get Cassidy to comment :)

Changed in gala:
assignee: nobody → elementary UX Team (elementary-design)
Revision history for this message
Cassidy James Blaede (cassidyjames) wrote :

Hm... ideally imho it should stay with the primary display, since that what the dock and panel do.

But I can see the difficulty of doing that (and am not sure it would make sense from the user's point of view). So I suppose doing it on the outside of multiple displays could work. Could get weird with some more-than-two display setups though. :-/

I think hotcorners plus multiple displays is a sticky situation. xD

Revision history for this message
Jaap Broekhuizen (jaapz-b) wrote :

Well, how it's currently done on the primary screen is definitely not how you would want it. It's very user unfriendly, because it's hard to hit the corners in the middle, while you can also easily hit it by accident when you are going from one screen to the other with the mouse. I think it's fairly logical to put the hotcorners on both outer sides of your total screen, as multiple monitors are meant to extend the total screen real estate you have.

The fact that the dock and panel do this is because that is the most user-friendly. Hotcorners are a very different kind of control system, they actually are less user friendly like that. You can't really compare those two as they serve a pretty different purpose and act in pretty different ways.

Revision history for this message
Danielle Foré (danrabbit) wrote :

What Jaap is saying seems very logical to me. I could see how you could accidentally trigger it by being on the primary display because in this case it's not longer a corner from the metal model of where the mouse is traveling. I think the big benefit of hot corners is throwing your mouse into the corner sort of haphazardly (fits law stuff). If its not actually a corner and more like a side, well that's not exactly how the feature is intended to work in the first place

Revision history for this message
Sergey "Shnatsel" Davidoff (shnatsel) wrote :

Got input from UX team, unassigning them and marking bug Triaged.
This is not a problem of the switchboard plug, marking invalid for it.

Changed in switchboard-plug-pantheon-shell:
status: New → Invalid
Changed in gala:
status: New → Confirmed
assignee: elementary UX Team (elementary-design) → nobody
status: Confirmed → Triaged
Cody Garver (codygarver)
Changed in gala:
importance: Undecided → Medium
Revision history for this message
delaytime0 (delaytime0) wrote :

in Gnome, this kind of problem is solved via a "mouse-stop" on the primary monitor.

If i push the mouse at the top-edge to the corner my mouse stops in the corner. So i cant miss the menu top-right.

Revision history for this message
michal lepicki (michal-lepicki) wrote :

My idea is:
-all hot corners can be used on the screen where my mouse pointer actually is
-hot corners have 'tolerance' of 75px, which prevents my mouse pointer from getting to another screen
-'Applications' menu shows up on the active screen (by active screen i mean the screen with my mouse pointer)
-workspace windows/all windows shouldn't be changed, they work great
-Minimalize/maximalize should change the top window of the screen, not the active window of the workspace

Revision history for this message
Jakub Dyszkiewicz (144-kuba) wrote :

I vote for Jaap solution to treat multiple displays as one big screen

Revision history for this message
beta992 (beta992) wrote :

Also having problems with dual-monitor and hotcorners. Sometimes they 'work' when going to a screen-corner, but most of the time they don't work at all.

I want to use the hot-corners for the workspace overview (fast switching) and window overview (all on the button left/right).

Latest gala, screens have different resolutions.

Revision history for this message
Mike Ellertson (mdellertson) wrote :

I thought I'd chime in with some additional info, well at least I think it's additional.

I'm running three monitors with resolutions as follows:

Monitor 1: 1680 x 1050 (left monitor)
Monitor 2: 1920 x 1080 (center monitor)
Monitor 3: 1680 x 1050 (right monitor)

Attempting to understand the possible root cause, I ran the following two test cases. For both test cases I have the same action assigned for each of the four hot-corners, namely 'Spread all Windows'.

1) Align the top edges of all three monitors, and move mouse to:
1.a. top right of right monitor
1.b. bottom right of right monitor
1.c. top left of left monitor
1.d. bottom left of left monitor

2) Align bottom edges of all three monitors, and move mouse to:
2.a. top right of right monitor
2.b. bottom right of right monitor
2.c. top left of left monitor
2.d. bottom left of left monitor

The 'Spread all Windows' action is triggered only for 1.a, 1,c, 2.b and 2.d.

The center monitor on my configuration has a slightly greater Y axis resolution than the left and right monitors, 1080 vs 1080 respectively. It seems to me like the issue might be caused, directly or indirectly, by hit detection for the hot-corner function only returning true using the following logic (actually I imagine the function isn't boolean, but I'm just using this as an example):

If mouse X value >= max X screen resolution value evaluate the two following statements:
Return true for bottom right corner if mouse Y value >= max Y screen resolution value
Return true for top right corner if mouse Y value <= min Y screen resolution value

If mouse X value <= min X screen resolution value evaluate the two following statements:
Return true for bottom left corner if mouse Y value >= max Y screen resolution value
Return true for top left corner if mouse Y value <= min Y screen resolution value

It seems like the issue might stem from the min and max Y variables being set using the min and max Y of all monitors. But, it seems like it might be better to set min and max Y value on a per monitor basis. That way the hot-corner hit detection logic could check to see if the mouse is on the right most or left most monitor and use its min and max Y values when evaluating corner hit detection.

There are a few ways I can imagine the framework being structured, which might make fixing this issue a bit more challenging. But, as I have no exposure to the Unity framework, I'm just guessing. :-)

I hope this helps, and on another note, I've been looking for a way to give back to the linux community. If I can roll up my sleeves and help out on this issue, I'd be happy to do so. If anyone can point me in the a good direction as a starting point, I'll see if I can help.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.