2012-02-20 16:54:49 |
Stewart Wilson |
bug |
|
|
added bug |
2012-02-20 16:56:01 |
Stewart Wilson |
bug task added |
|
ayatana-design |
|
2012-02-20 16:56:07 |
Stewart Wilson |
ayatana-design: status |
New |
Triaged |
|
2012-02-20 16:56:15 |
Stewart Wilson |
ayatana-design: importance |
Undecided |
High |
|
2012-02-20 16:56:20 |
Stewart Wilson |
ayatana-design: assignee |
|
Stewart Wilson (stewartw) |
|
2012-02-20 16:56:58 |
Stewart Wilson |
bug task added |
|
unity |
|
2012-02-20 16:59:07 |
Stewart Wilson |
description |
On a multimonitor setup, whilst the HUD is displayed the mouse cursor cannot pass from right to left unless travelling at high velocity (ie. not looking to trigger a launcher reveal). Travelling from left to right there is no issue.
The problem appears to be that when a launcher reveal would normally be in the process of being triggered on the left edge of a display, this is overriden whilst the HUD is open, causing the mouse cursor to fight indefinitely at the edge of the display to pass.
Solution:
At display boundaries, the first hold, for the Launcher reveal when travelling from right to left, should be bypassed when the HUD is displayed. The second hold (the hold which is symmetric in both left and right directions) should be kept. |
On a multimonitor setup, with the Launcher behaviour set to Auto-hide, whilst the HUD is displayed the mouse cursor cannot pass from right to left unless travelling at high velocity (ie. not looking to trigger a launcher reveal). Travelling from left to right there is no issue.
The problem appears to be that when a launcher reveal would normally be in the process of being triggered on the left edge of a display, this is overriden whilst the HUD is open, causing the mouse cursor to fight indefinitely at the edge of the display to pass.
Solution:
At display boundaries, the first hold, for the Launcher reveal when travelling from right to left, should be bypassed when the HUD is displayed. The second hold (the hold which is symmetric in both left and right directions) should be kept. |
|
2012-02-21 01:32:44 |
Bilal Akhtar |
unity: status |
New |
Incomplete |
|
2012-02-21 01:32:48 |
Bilal Akhtar |
unity (Ubuntu): status |
New |
Incomplete |
|
2012-02-21 17:19:52 |
Omer Akram |
unity: status |
Incomplete |
Confirmed |
|
2012-02-21 17:19:55 |
Omer Akram |
unity (Ubuntu): status |
Incomplete |
Confirmed |
|
2012-04-17 16:31:37 |
John Lea |
unity: milestone |
|
backlog |
|
2012-04-17 16:32:10 |
John Lea |
description |
On a multimonitor setup, with the Launcher behaviour set to Auto-hide, whilst the HUD is displayed the mouse cursor cannot pass from right to left unless travelling at high velocity (ie. not looking to trigger a launcher reveal). Travelling from left to right there is no issue.
The problem appears to be that when a launcher reveal would normally be in the process of being triggered on the left edge of a display, this is overriden whilst the HUD is open, causing the mouse cursor to fight indefinitely at the edge of the display to pass.
Solution:
At display boundaries, the first hold, for the Launcher reveal when travelling from right to left, should be bypassed when the HUD is displayed. The second hold (the hold which is symmetric in both left and right directions) should be kept. |
On a multimonitor setup, with the Launcher behaviour set to Auto-hide, whilst the HUD is displayed the mouse cursor cannot pass from right to left unless travelling at high velocity (ie. not looking to trigger a launcher reveal). Travelling from left to right there is no issue.
The problem appears to be that when a launcher reveal would normally be in the process of being triggered on the left edge of a display, this is overriden whilst the HUD is open, causing the mouse cursor to fight indefinitely at the edge of the display to pass.
------------------------------
Desired solution:
At display boundaries, the first hold, for the Launcher reveal when travelling from right to left, should be bypassed when the HUD is displayed. The second hold (the hold which is symmetric in both left and right directions) should be kept. |
|
2012-04-20 04:27:36 |
Tim Penhey |
ayatana-design: status |
Triaged |
Fix Committed |
|
2012-09-14 02:35:15 |
Tim Penhey |
unity: milestone |
backlog |
|
|
2012-10-09 12:38:53 |
John Lea |
unity: status |
Confirmed |
Triaged |
|
2012-10-09 12:38:56 |
John Lea |
unity (Ubuntu): status |
Confirmed |
Triaged |
|
2012-10-09 12:39:03 |
John Lea |
tags |
multimonitor udp |
hud multimonitor udp |
|
2012-10-09 12:39:06 |
John Lea |
unity: importance |
Undecided |
High |
|
2012-10-09 12:39:08 |
John Lea |
unity (Ubuntu): importance |
Undecided |
High |
|
2012-10-09 12:39:10 |
John Lea |
ayatana-design: assignee |
Stewart Wilson (stewartw) |
John Lea (johnlea) |
|
2013-06-06 15:24:41 |
Nicolas paoloni |
bug |
|
|
added subscriber Nicolas paoloni |
2015-09-20 20:08:25 |
Andrea Azzarone |
unity: status |
Triaged |
Invalid |
|
2015-09-20 20:08:29 |
Andrea Azzarone |
unity (Ubuntu): status |
Triaged |
Invalid |
|