[FFe] Launcher, Window Management - More Effective window switching for apps with multiple windows using the Launcher

[Kay]

It would be very useful if you could simply hover over an icon of an open app and scroll with the mouse wheel to switch and highlight between the windows of that app, if it has more.

---------------------------------
Desired resolution:

Try implementing the following as an experiment. Before the change described below lands in Ubuntu *it must first be user tested, and reviewed by the design team*

If the pointer is positioned over the Launcher icon of an application that is in focus which has multiple windows open in the following order A,B,C,D,E:

- Scrolling the mouse wheel 'one click towards the user' should display the next window (B) of the application in the Z stack. e.g.
        Starting Z stack order: A,B,C,D,E
        Output Z stack order: B,A,C,D,E

- Scrolling the mouse wheel 'one click away from the user' should display the bottom window (E) in the application in the Z stack
        Starting Z stack order: A,B,C,D,E
        Output Z stack order: E,A,B,C,D

- Scrolling the mouse wheel 'two clicks towards the user' should first briefly display the next window of the application in the Z stack (window B) after the first mousewheel click, and then on the second mousewheel click return window B to it's previous position in the z-stack and display window C.
        Starting Z stack order: A,B,C,D,E
        Output Z stack order: C,A,B,D,E

- Scrolling the mouse wheel 'two clicks away from the user' should first briefly display the bottom window of the application in the Z stack (window E) after the first mousewheel click, and then on the second mousewheel click return window E to it's previous position in the z-stack and display the next most bottom window, window D.
        Starting Z stack order: A,B,C,D,E
        Output Z stack order: D,A,B,C,E

- Scrolling the mouse wheel 'three clicks towards the user' should first briefly display the next window of the application in the Z stack (window B) after the first mousewheel click, and then return window B to it's previous position in the z-stack and briefly display the next window of the application in the Z stack (window C) after the second mousewheel click, and then on the third mousewheel click return window C to it's previous position in the z-stack and display window D.
        Starting Z stack order: A,B,C,D,E
        Output Z stack order: D,A,B,C,E

- etc, etc... for more windows and more mouse wheel clicks in either direction.

If the application *is not* in focus when the user moves their pointer over the Launcher app icon, the first mouse wheel click towards or away from the user should focus the application, and bring the top most window in the application's z stack to the front of the global z stack. Subsequent clicks of the mouse wheel the operate exactly as described above.

If the application is not running, or has only one open window mouse wheel clicking towards or away from the user when the pointer is over the application's launcher icon should do nothing.

Because this behaviour will conflict with the current use of the mouse wheel to scroll the launcher, the mouse wheel launcher scroll should be changed to only work when the ALT key is held down. e.g. to scroll the launcher with the mouse wheel the user will have to press ALT + MOUSEWHEEL UP or press ALT + MOUSEWHEEL DOWN

-------------------------
Additional test case defining the interaction with minimised windows:

hyia, minimised windows should be at the back of the stack. So if App 1 has have windows A, B, and C (stacking order) and you minimise window A, and then focus App 2, when you move your pointer over the launcher icon of App 2 and scroll the mousewheel one click, window B should appear. Moving the mouse wheel one more click should then show window C. Moving the mouse wheel one more click should then show window A. Moving the mouse wheel one more click should then show window B. Moving the pointer so that it is no longer over the launcher icon of app A at this point should focus window B. Window A should remain minimised.

[Daniel van Vugt (vanvugt)]

Removed the second feature request from the bug description about minimizing windows. That's already discussed in bug 733349.

[Kay (ksthiele)]

"Because this behaviour will conflict with the current use of the mouse wheel to scroll the launcher, the mouse wheel launcher scroll should be changed to only work when the ALT key is held down. e.g. to scroll the launcher with the mouse wheel the user will have to press ALT + MOUSEWHEEL UP or press ALT + MOUSEWHEEL DOWN"

or the user has to move over the arrows on the edge of the screen.

[Christophe C (batra3)]

I support the idea of kay

[Roman Yepishev (rye)]

I have some doubts regarding mouse wheel usage in this case - in a laptop where mousewheel is physically not present on a touchpad, scrolling would not generate distinct "clicks" therefore selecting that particular window would look more like back and forth stabilization movement than directed and definite selection.

[Daniel van Vugt (vanvugt)]

Roman,

Unfortunately, still, for most applications the mouse wheel _and_ touchpad scrolling are implemented as emitting button click 4 (up) and 5 (down). But yeah you still have the problem of touchpad scrolling not being discretely incremental.

[Andrea Azzarone (azzar1)]

@John should it wrap?

[John Lea (johnlea)]

@andyrock; yes it should wrap

[Andrea Azzarone (azzar1)]

@John, what should happen in this case?

You minimize a window, of app A (which has more than one window), then you focus another application B, and you scroll over A icon.

[Önder (onder.bakirtas)]

I have a solution for this. If a program has more than one window, user should click to reveal open windows thumbnails. This process also can be achieved by a mini-delay, like 0.5 seconds.

[Bruce (brunces)]

I'm glad do know such feature is being propose because I would really like to have this option on my Unity's Launcher.

I'm not a developer, so I don't know whether my idea is possible or not, but I think this scrolling feature would be fantastic if it could simply invoke that same animation we get when we press "Alt + (key above Tab)". I mean, since the point is switching between windows of the same application, why not use the same animation both for "Alt + (key above Tab)" and scrolling the wheel over the application icon? For me, it makes perfect sense.

Is that possible? What do you think? :)

Cheers, guys.

brunces

[Bruce (brunces)]

(Correction for my previous post...)

"I'm glad TO know such feature is being PROPOSED because..."

By the way, I would like to be a tester. If possible, just let me know. Thanks. :)

brunces

[Dereck Wonnacott (dereck)]

I'm not sure how best to voice my support for this feature, but I too would really appreciate it!

[Tankypon (tankypon)]

I agree with Önder. I prefer that windows thumbnails appear with a mini-delay when the cursor is on the application's picture. We only have to move the mouse on the picture of the opened application to reveal each of his windows. Somewhat like Windows 7, I believe.

But this is just my opinion. Each user has his opinion. In this context, it would be really good if the user have multiple choici to invoke windows thumbnails : by example, with scrolling.

[CSRedRat (csredrat)]

Great switching method! Good luck!

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:unity at revision None, scheduled for release in unity, milestone backlog

[Stefano Rivera (stefanor)]

re the FFe: This stuff auto-lands in Ubuntu, and was already committed before the Feature Freeze, so I'm happy to just wave it through on the next automatic upload.

In future, though, new features should get FFes before being committed to trunk, I think.

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity - 6.12.0daily13.03.08-0ubuntu1

---------------
unity (6.12.0daily13.03.08-0ubuntu1) raring; urgency=low

  [ Andrea Azzarone ]
  * Launcher, Window Management - More Effective window switching for
    apps with multiple windows using the Launcher (LP: #1081843)

  [ Automatic PS uploader ]
  * Automatic snapshot from revision 3199
 -- Automatic PS uploader <email address hidden> Fri, 08 Mar 2013 10:34:28 +0000

[Stephen M. Webb (bregma)]

Fix Released in Unity Unity 7.0.0 "R series".

[Teo (teo1978)]

Note that the implementation of this feature is broken.

See https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1263786

[Teo (teo1978)]

It's broken in that:

1 - if you hover the icon of an app OTHER THAN THE ONE CURRENTLY FOCUSED and move the scrollwheel, you'll steal focus from the currently focused app and give it to another. And that is not reversible by moving back the scrollwheel.
In other words, this should only work on the icon of the app that currently has focus. .

And as a special case particularly annoying:

2 - this even happens if you hover on an icon of an app that HAS ONLY ONE WINDOW and move the scrollwheel.

[Teo (teo1978)]

Oh my god, point (1) was by design!

"""If the application *is not* in focus when the user moves their pointer over the Launcher app icon, the first mouse wheel click towards or away from the user should focus the application, and bring the top most window in the application's z stack to the front of the global z stack. Subsequent clicks of the mouse wheel the operate exactly as described above"""

For god's sake, this part needs to be reconsidered.

There is a basic principle in the way mouse wheel interaction has ALWAYS worked EVERYWHERE and you're breaking it here, and it's not a good innovation.
The mousewheel is used to move "something" forward and backward, and if you move it forwards and then backwards (or viceversa) of an equal amount, you go back to the original status.
Think about the way it is used for scrolling a page, or zooming in and out in an image editor, or (I hate it but unfortunately it's become widespread) switching between tabs in a browser, or between choices in a dropdown menu (even without unfolding it, regrettably, but again that's become popular). In all cases, the rule is never broken: if you move one step too much in one direction, either intentionally or accidentally (the latter being very common) you can always go back by moving the wheel one step in the following direction.

Now even if point 2 gets fixed , which is clearly a bug and contraddicts the "requirements" stated in this request (see #1263786), you are still breaking the "reversibility" of mouse wheel movements.

[Mark Shuttleworth (sabdfl)]

On 10/01/14 00:52, matteo sisti sette wrote:
> Oh my god, point (1) was by design!
>
> """If the application *is not* in focus when the user moves their
> pointer over the Launcher app icon, the first mouse wheel click towards
> or away from the user should focus the application, and bring the top
> most window in the application's z stack to the front of the global z
> stack. Subsequent clicks of the mouse wheel the operate exactly as
> described above"""
>

Yes, that is a mistake, scrollwheel-window-launcher behaviour should
only be effective for the focused application. +1 to fix.

Mark

[Christopher Townsend (townsend)]

I opened bug #1267888 to fix the incorrect design issue per Mark's comment.

[Alan Bell (alanbell)]

as a result of this change, mouse wheel on other launcher icons does nothing useful at all and mouse wheel on the focussed app icon switches windows in a different way, it certainly isn't reverse-able like it was, it is deterministic, but I am struggling to describe the rule, if you rock one click back and forth on the mouse wheel it flips between one window and each of the others in turn. Prior to the update it flipped back and forth between two windows - which preserves the nature of the mouse wheel, if you use it to flip between windows and go past the window you wanted, a reverse click now takes you to a different window.

[Tin Tvrtkovic (tinchester)]

I found using the scroll wheel to bring unfocused application into focus was very convenient, so it's a little disappointing it's getting removed.

Also, I agree scrolling through open windows of an application should behave in a ring-like manner; every scroll should be reversible.