| 2011-09-07 14:54:45 |
Andy Choens |
bug |
|
|
added bug |
| 2011-09-18 18:19:59 |
Omer Akram |
tags |
accessibility usability |
accessibility multimonitor usability |
|
| 2011-09-23 19:14:59 |
David Barth |
bug task added |
|
ayatana-design |
|
| 2011-09-23 19:15:14 |
David Barth |
tags |
accessibility multimonitor usability |
accessibility mm-dash multimonitor usability |
|
| 2011-09-23 19:15:29 |
David Barth |
unity: status |
New |
Triaged |
|
| 2011-09-23 19:15:34 |
David Barth |
unity: importance |
Undecided |
Low |
|
| 2011-09-24 10:08:52 |
Omer Akram |
bug task added |
|
unity (Ubuntu) |
|
| 2011-09-24 10:09:09 |
Omer Akram |
unity (Ubuntu): importance |
Undecided |
Low |
|
| 2011-09-24 10:09:11 |
Omer Akram |
unity (Ubuntu): status |
New |
Triaged |
|
| 2011-10-07 10:36:15 |
John Lea |
description |
When using my laptop with an external monitor attached, Unity behaves in an unexpected manner. Below, is a basic outline of how I have my monitors set up using Gnome3's Display utility.
-------------------------------------
| | -------------------------------------
| External Monitor (#1) || Laptop Screen (#2) |
| || |
------------------------------------- -------------------------------------
I'm not sure what the proper name for the menu/indicator bar that runs across the top of the screen is. Here, I refer to it as the Unity menu bar.
My problem is this - when using multiple monitors, with maximized applications, it is difficult to use the mouse to switch focus from one app to the other. In my mind, the Unity menu bar must act as both a menu bar and a traditional window title border when applications are maximized. In single screen mode, this works as I expect it to. For example, I can reach up to the Unity menu bar and drag down to de-maximize the window.
But, this pattern/metaphor seems to break down when using multiple monitors. Let's say I have Firefox maximized on #1 and Thunderbird maximized #2. I start by using Firefox. Thus, Firefox is the application in focus. As long as continue to interact with Firefox, everything behaves as I expect it to. The problem starts when I want to shift focus to Thunderbird running on #2. If I use Alt-Tab, everything works as expected because Unity properly understands that I have shifted focus to Thunderbird. But, if I use my mouse to switch focus, Unity's behavior is not logical. Let's say I drag my mouse from Firefox to Thunderbird and attempt to interact with the Thunderbird menu, which is in the top-left corner of #2. Because Firefox still has the focus, I can not immediately access Thunderbird's menus. The Unity menu bar stays blank. This is confusing, but not the end of the world. It gets worse when the user discovers that clicking on the Unity menu bar that is positioned above Thunderbird does not cause Thunderbird to obtain focus. In this situation, the idea that the Unity menu bar is a title bar and menu breaks down because I can not give Thunderbird focus using the maximized title bar. The only way to switch focus to Thunderbird involves selecting some non-functional chrome in the Thunderbird window. Once I have clicked on Thunderbird, it has the focus and the menus and title bar behave as expected.
This is similar to bug #716177 but the recent fixes don't seem to have the desired affect.
Metacity had the option to have focus follow the mouse. In most use cases, this is incredibly frustrating. But, when using maximized windows in dual monitor set ups, this is actually much more natural. Unity should have some way of detecting when it should switch gears and allow focus to follow mouse and when it should wait for a click to switch focus.
I hope this all makes sense. |
When using my laptop with an external monitor attached, Unity behaves in an unexpected manner. Below, is a basic outline of how I have my monitors set up using Gnome3's Display utility.
-------------------------------------
| | -------------------------------------
| External Monitor (#1) || Laptop Screen (#2) |
| || |
------------------------------------- -------------------------------------
I'm not sure what the proper name for the menu/indicator bar that runs across the top of the screen is. Here, I refer to it as the Unity menu bar.
My problem is this - when using multiple monitors, with maximized applications, it is difficult to use the mouse to switch focus from one app to the other. In my mind, the Unity menu bar must act as both a menu bar and a traditional window title border when applications are maximized. In single screen mode, this works as I expect it to. For example, I can reach up to the Unity menu bar and drag down to de-maximize the window.
But, this pattern/metaphor seems to break down when using multiple monitors. Let's say I have Firefox maximized on #1 and Thunderbird maximized #2. I start by using Firefox. Thus, Firefox is the application in focus. As long as continue to interact with Firefox, everything behaves as I expect it to. The problem starts when I want to shift focus to Thunderbird running on #2. If I use Alt-Tab, everything works as expected because Unity properly understands that I have shifted focus to Thunderbird. But, if I use my mouse to switch focus, Unity's behavior is not logical. Let's say I drag my mouse from Firefox to Thunderbird and attempt to interact with the Thunderbird menu, which is in the top-left corner of #2. Because Firefox still has the focus, I can not immediately access Thunderbird's menus. The Unity menu bar stays blank. This is confusing, but not the end of the world. It gets worse when the user discovers that clicking on the Unity menu bar that is positioned above Thunderbird does not cause Thunderbird to obtain focus. In this situation, the idea that the Unity menu bar is a title bar and menu breaks down because I can not give Thunderbird focus using the maximized title bar. The only way to switch focus to Thunderbird involves selecting some non-functional chrome in the Thunderbird window. Once I have clicked on Thunderbird, it has the focus and the menus and title bar behave as expected.
This is similar to bug #716177 but the recent fixes don't seem to have the desired affect.
Metacity had the option to have focus follow the mouse. In most use cases, this is incredibly frustrating. But, when using maximized windows in dual monitor set ups, this is actually much more natural. Unity should have some way of detecting when it should switch gears and allow focus to follow mouse and when it should wait for a click to switch focus.
I hope this all makes sense.
----------------------------------------------------------
Desired solution:
- When a user has a maximised application open on a second monitor, and a different window is in focus, clicking on any empty area in the second monitor top bar should bring the non-focused application that is currently maximised on the second monitor in to focus.
- When a user has a maximised application open on a second monitor, and a different window is in focus, the normal 'drag any empty area in the top bar downwards to shift window from maximised to restored state' behaviour should apply. |
|
| 2011-10-07 10:36:25 |
John Lea |
tags |
accessibility mm-dash multimonitor usability |
accessibility mm-dash multimonitor onew udo usability |
|
| 2011-10-07 10:36:30 |
John Lea |
ayatana-design: assignee |
|
John Lea (johnlea) |
|
| 2011-10-07 10:36:33 |
John Lea |
ayatana-design: importance |
Undecided |
Critical |
|
| 2011-10-07 10:36:36 |
John Lea |
ayatana-design: status |
New |
Fix Committed |
|
| 2011-10-07 10:36:39 |
John Lea |
unity: importance |
Low |
Critical |
|
| 2011-10-07 11:13:33 |
John Lea |
description |
When using my laptop with an external monitor attached, Unity behaves in an unexpected manner. Below, is a basic outline of how I have my monitors set up using Gnome3's Display utility.
-------------------------------------
| | -------------------------------------
| External Monitor (#1) || Laptop Screen (#2) |
| || |
------------------------------------- -------------------------------------
I'm not sure what the proper name for the menu/indicator bar that runs across the top of the screen is. Here, I refer to it as the Unity menu bar.
My problem is this - when using multiple monitors, with maximized applications, it is difficult to use the mouse to switch focus from one app to the other. In my mind, the Unity menu bar must act as both a menu bar and a traditional window title border when applications are maximized. In single screen mode, this works as I expect it to. For example, I can reach up to the Unity menu bar and drag down to de-maximize the window.
But, this pattern/metaphor seems to break down when using multiple monitors. Let's say I have Firefox maximized on #1 and Thunderbird maximized #2. I start by using Firefox. Thus, Firefox is the application in focus. As long as continue to interact with Firefox, everything behaves as I expect it to. The problem starts when I want to shift focus to Thunderbird running on #2. If I use Alt-Tab, everything works as expected because Unity properly understands that I have shifted focus to Thunderbird. But, if I use my mouse to switch focus, Unity's behavior is not logical. Let's say I drag my mouse from Firefox to Thunderbird and attempt to interact with the Thunderbird menu, which is in the top-left corner of #2. Because Firefox still has the focus, I can not immediately access Thunderbird's menus. The Unity menu bar stays blank. This is confusing, but not the end of the world. It gets worse when the user discovers that clicking on the Unity menu bar that is positioned above Thunderbird does not cause Thunderbird to obtain focus. In this situation, the idea that the Unity menu bar is a title bar and menu breaks down because I can not give Thunderbird focus using the maximized title bar. The only way to switch focus to Thunderbird involves selecting some non-functional chrome in the Thunderbird window. Once I have clicked on Thunderbird, it has the focus and the menus and title bar behave as expected.
This is similar to bug #716177 but the recent fixes don't seem to have the desired affect.
Metacity had the option to have focus follow the mouse. In most use cases, this is incredibly frustrating. But, when using maximized windows in dual monitor set ups, this is actually much more natural. Unity should have some way of detecting when it should switch gears and allow focus to follow mouse and when it should wait for a click to switch focus.
I hope this all makes sense.
----------------------------------------------------------
Desired solution:
- When a user has a maximised application open on a second monitor, and a different window is in focus, clicking on any empty area in the second monitor top bar should bring the non-focused application that is currently maximised on the second monitor in to focus.
- When a user has a maximised application open on a second monitor, and a different window is in focus, the normal 'drag any empty area in the top bar downwards to shift window from maximised to restored state' behaviour should apply. |
When using my laptop with an external monitor attached, Unity behaves in an unexpected manner. Below, is a basic outline of how I have my monitors set up using Gnome3's Display utility.
-------------------------------------
| | -------------------------------------
| External Monitor (#1) || Laptop Screen (#2) |
| || |
------------------------------------- -------------------------------------
I'm not sure what the proper name for the menu/indicator bar that runs across the top of the screen is. Here, I refer to it as the Unity menu bar.
My problem is this - when using multiple monitors, with maximized applications, it is difficult to use the mouse to switch focus from one app to the other. In my mind, the Unity menu bar must act as both a menu bar and a traditional window title border when applications are maximized. In single screen mode, this works as I expect it to. For example, I can reach up to the Unity menu bar and drag down to de-maximize the window.
But, this pattern/metaphor seems to break down when using multiple monitors. Let's say I have Firefox maximized on #1 and Thunderbird maximized #2. I start by using Firefox. Thus, Firefox is the application in focus. As long as continue to interact with Firefox, everything behaves as I expect it to. The problem starts when I want to shift focus to Thunderbird running on #2. If I use Alt-Tab, everything works as expected because Unity properly understands that I have shifted focus to Thunderbird. But, if I use my mouse to switch focus, Unity's behavior is not logical. Let's say I drag my mouse from Firefox to Thunderbird and attempt to interact with the Thunderbird menu, which is in the top-left corner of #2. Because Firefox still has the focus, I can not immediately access Thunderbird's menus. The Unity menu bar stays blank. This is confusing, but not the end of the world. It gets worse when the user discovers that clicking on the Unity menu bar that is positioned above Thunderbird does not cause Thunderbird to obtain focus. In this situation, the idea that the Unity menu bar is a title bar and menu breaks down because I can not give Thunderbird focus using the maximized title bar. The only way to switch focus to Thunderbird involves selecting some non-functional chrome in the Thunderbird window. Once I have clicked on Thunderbird, it has the focus and the menus and title bar behave as expected.
This is similar to bug #716177 but the recent fixes don't seem to have the desired affect.
Metacity had the option to have focus follow the mouse. In most use cases, this is incredibly frustrating. But, when using maximized windows in dual monitor set ups, this is actually much more natural. Unity should have some way of detecting when it should switch gears and allow focus to follow mouse and when it should wait for a click to switch focus.
I hope this all makes sense.
----------------------------------------------------------
Desired solution:
- When a user has a maximised application open on a second monitor, and a different window is in focus, clicking on any empty area in the second monitor top bar should bring the non-focused application that is currently maximised on the second monitor in to focus.
- When a user has a maximised application open on a second monitor, and a different window is in focus, the normal 'drag any empty area in the top bar downwards to shift window from maximised to restored state' behaviour should apply. (see bug https://bugs.launchpad.net/ayatana-design/+bug/723882 for a description of this functionality) |
|
| 2011-10-07 11:36:01 |
John Lea |
summary |
Multi-Monitor Maximized Difficulty |
multimonitor , window management - Multi-Monitor Maximized Difficulty |
|
| 2011-10-11 11:07:51 |
Sam Spilsbury |
unity: milestone |
|
4.26.0 |
|
| 2011-10-11 11:07:54 |
Sam Spilsbury |
unity (Ubuntu): assignee |
|
Sam Spilsbury (smspillaz) |
|
| 2011-10-11 16:34:27 |
Sam Spilsbury |
unity: importance |
Critical |
Medium |
|
| 2011-10-11 16:34:38 |
Sam Spilsbury |
unity (Ubuntu): status |
Triaged |
In Progress |
|
| 2011-10-11 16:56:22 |
Launchpad Janitor |
branch linked |
|
lp:~smspillaz/unity/unity.fix_843958 |
|
| 2011-10-11 17:32:02 |
Sam Spilsbury |
unity: status |
Triaged |
Fix Committed |
|
| 2011-10-11 17:32:05 |
Sam Spilsbury |
unity (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2011-10-18 13:14:16 |
John Lea |
ayatana-design: status |
Fix Committed |
Triaged |
|
| 2011-10-18 13:14:28 |
John Lea |
tags |
accessibility mm-dash multimonitor onew udo usability |
accessibility mm-dash multimonitor onew udo udp usability |
|
| 2011-11-03 15:48:23 |
John Lea |
unity: assignee |
|
Andrea Azzarone (andyrock) |
|
| 2011-11-03 15:48:34 |
John Lea |
unity: milestone |
4.26.0 |
5.0.0 |
|
| 2011-11-03 15:48:56 |
John Lea |
unity: assignee |
Andrea Azzarone (andyrock) |
|
|
| 2011-11-03 15:49:01 |
John Lea |
ayatana-design: status |
Triaged |
Fix Committed |
|
| 2011-11-21 03:07:53 |
Tim Penhey |
unity: assignee |
|
Sam Spilsbury (smspillaz) |
|
| 2011-12-08 08:32:10 |
Omer Akram |
unity (Ubuntu): importance |
Low |
Medium |
|
| 2011-12-19 20:50:41 |
Bryce Harrington |
tags |
accessibility mm-dash multimonitor onew udo udp usability |
accessibility mm-dash multimonitor onew precise udo udp usability |
|
| 2012-01-11 15:45:15 |
Greg A |
bug |
|
|
added subscriber Greg Auger |
| 2012-01-12 17:47:17 |
Didier Roche-Tolomelli |
unity: status |
Fix Committed |
Fix Released |
|
| 2012-01-13 08:15:58 |
Launchpad Janitor |
unity (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2012-01-13 08:45:31 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/unity |
|
| 2012-02-10 22:48:37 |
Robert Jordens |
bug |
|
|
added subscriber Robert Jordens |
| 2012-02-20 15:42:44 |
John Lea |
ayatana-design: importance |
Critical |
High |
|
| 2012-03-07 11:40:18 |
Nick Tait |
tags |
accessibility mm-dash multimonitor onew precise udo udp usability |
furtherdesignreviewrequiredp |
|
| 2012-03-07 11:54:35 |
Nick Tait |
tags |
furtherdesignreviewrequiredp |
furtherdesignreviewrequiredp udp |
|
| 2012-04-26 10:24:47 |
John Lea |
tags |
furtherdesignreviewrequiredp udp |
reviewedbydesignp |
|
| 2012-04-26 10:25:06 |
John Lea |
ayatana-design: status |
Fix Committed |
Fix Released |
|
| 2012-04-26 10:42:44 |
Greg A |
removed subscriber Greg Auger |
|
|
|
