** Also affects: unity (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity in Ubuntu.
Matching subscriptions: dp-unity
https://bugs.launchpad.net/bugs/1286784
Title:
Inconsistent scrollwheel launcher behavior for window switching.
Status in Unity:
New
Status in “unity” package in Ubuntu:
New
Bug description:
Background:
I believe it first landed in 13.04 that scrolling the mouse wheel over
launcher icons would flip through multiple windows of that app or do nothing if
that app was not open. IMO, this is exactly what Unity was missing that I
couldn't put a finger on for myself and I love it!! This worked exactly as
described there for all lauchers regardless of what app was focused.
Apparently, working on unfocused apps was unintentional but at this point it
has been in use in the wild for a while. This unintended "feature" has recently
been removed in the fix for #1263786 and #1267888.
Current Sitution:
The recurring theory in this scrollwheel discussion has been that whatever
scrolling in one direction does, scrolling in the opposite direction should
undo. The primary focus of this bug is just to define where such opposite
scrolling needs fixing. But it must also be pointed out that fixing these
behaviors resolves some complaints against the aforementioned unintended
feature making its removal unnecessary. And a consistent approach to this could
also solve some other hotly requested use cases.
1. Single App Use Case
1.1. Steps to Reproduce
1.1.1. Open 4 Terminals. They should naturally position into the 4 corners so
let's refer to them as NorthWest, NorthEast, SouthWest, SouthEast (NW, NE, SW,
SE).
1.1.2. Click through them all to force a Z order. Of course the Z order will
be the opposite of the click order so I click through them intentionally
"backwards" bottom to top and right to left: SE, SW, NE, NW. My Z order is now
NW, NE, SW, SE; NW is the focused window.
1.1.3. Mouseover Terminal Launcher and Scrollwheel Down Repeatedly,
eventually coming to rest on NW again as the focused window. This proceeds
through and loops the Z order as expected: NW, NE, SW, SE, ... NW
1.1.4. Mouseover Terminal Launcher and Scrollwheel Up Repeatedly, eventually
coming to rest again on NW. This reverses through and loops the Z order as
expected: SE, SW, NE, NW ... NW
1.1.5 Mouseover Terminal Launcher and Scrollwheel Down 1 notch and then Up 1
notch.
1.2. Expected Results: Down Goes from NW to NE and Up goes back from NE to
NW. Z order should remain unchanged: NW, NE, SW, SE.
1.3. Actual Results: Down Goes from NW to NE and Up goes from NE to SE.
1.4. Reasoning: The Up abrubtly terminates the Down process causing NE to
gain focus and leaving the new Z order NE, NW, SW, SE. Now the new Up process
immediately processes from the bottom of the Z order to SE. Presumably if this
Up process is completed here and SE gains focus the Z order ends at SE, NE, NW,
SW. This can be confirmed by swicthing direction again and scrolling down
repeatedly.
1.5. Preferred Fix: Scrollwheel Up and Down should proceed through the Z
order but should not be independent. In other words, an App Launcher Scrolling
Event on the focused should grab and freeze the Z order of all App windows and
scroll through the them, up or down, until all scrolling is done.
1.6. Alternative Fix: If Scrolling were changed to proceed through some sort
of spacial relationship instead of Z order it would not matter if they were
independent. However, behavior for windows of identical geometry would then be
undefined.
1.7. Alternative Fix: If Scrolling were changed to always proceed through the
order shown in the Launcher context menu it would not matter. This would also
most closely resemble previous mouse wheel behavior on the old Gnome 2 window
list panel. Presumably this ordering is defined by window creation order or
"age."
2. Multitasking Use Case
2.1 Steps to Reproduce
2.1.1. Same as 1.1.1. Open 4 Terminals.
2.1.2. Same as 1.1.2. Force Z Order NW, NE, SW, SE.
2.1.3. Click Other Launcher. Other App (Firefox in my case) is
opened/focused. The effects of later steps are easiest to noticed when this
other App is maximized.
2.1.4. Click Terminal Launcher. As expected NW Terminal is focused; all other
terminals remain below Other App (OA). Z Order is NW, OA.
2.1.5. Scrollweel Down Repeatedly. This is a part of the genius of the whole
Scrollwheel feature!! As expected, this cycles through the terminals in Z order
but always keeps Other app immediately below the topmost terminal. The end-user
effect of this behavior is cycling through the terminal windows 1 at a time and
never losing sight that the "other" app _should_ end up as the next most recent
overall window. After 1 notch of scroll Z order is NE, OA. After another notch
of scroll Z Order is SW, OA.
2.1.6. Once again, changing scroll direction after the fact has unwelcomed
results similar to the single app use case problem and the "other" app
imediately loses its place in the overall Z order. But this is not the primary
problem with the 2 app use case.
2.1.7. Repeat 2.1.1 - 2.1.4. to get a clean slate for initial scrolling
direction.
2.1.8. Scroll Up instead of Down.
2.2. Expected Results: Initial Scroll Up Should behave exactly as Initial
Scroll Down but in opposite Z Order. Which is to say that after 1 notch Z Order
should go from NW, OA to SE, OA. After another notch should be SW, OA.
2.3. Actual Results: After Scroll Up 1 notch it goes from NW, OA to SE, NW,
OA. After another notch it is SW, SE, NW, OA.
2.4. Reasoning: I'm not quite sure. It is entirely possible that the Scroll
Down behavior is another unintented feature but it is quite good.
2.5. Prefered Fix: Scrolling on Launcher of newly focused App or of unfocused
App should grab and freeze the Z Order of all App windows plus insert the
Previously focused window and scroll through them, up or down, until all
scrolling is done.
2.5.1. Click Case: From NW, NE. Click OA for OA, NW, NE. Click NW for NW, OA.
Scroll Down for NE, OA. Scroll Up for back to NW, OA. Scroll Up again for OA,
NW. This is effectively an un-do for Click NW.
2.5.2. Un-Do Case: From OA, NW, NE. Click NW for NW, OA. Scroll Up for OA,
NW, NE. This is the hotly requested feature of a "peek" at NW and return to OA
*without* extra mouse travel to Click OA. The common request for this feature
is usually worded as "clicking launcher again should hide app." However this
implementation of it is completely consistent with opposing scroll behaviors.
2.5.3. No-Click Case: From OA, NW, NE. Mouseover NW Launcher and Scroll Down
for NW, OA. Scroll Down again for NE, OA. Scroll Up for NW, OA. Scroll Up again
for OA, NW, NE. This brings back the recently removed accidental feature but
fixes the common error that the behavior was not easily un-doable.
2.5.4. Peek Case for Power Users: Mouseover any unfocused Launcher and Scroll
1 notch to focus and opposite notch to un-do. Note that for single window Apps
it makes no difference if you scroll up then down or down then up.
2.5.5. No Launch Case: For complete consistency of this action doing
something useful but un-doable, Scrollwheel on un-opened launchers or empty
space of the dockbar should switch between 2 most recent windows directly. For
completeness, AFAIK this is the only mouse equivalent of 1 quick alt+tab and
release that is still usable on maximized windows.
Take answers 1.5 and 2.5 and 2.5.5 all together and I believe you have
a very consistent approach. Scrolling a launcher always switches focus
as long as there are windows open to focus. The currently focused
window is always included in this "scroll stack" regardless of which
launcher was scrolled on. The laucher scrolled on always has all of
its windows in the "scroll stack" regardless of which had focus. And
in the base case of the un-opened launcher scrolled on the scrolling
still takes place but the launcher simply has no windows to contribute
to the "scroll stack."
But again, scrollwheel behavior is simply inconsistent as it exists in
its current form. I go into great detail of possibilities and use
cases because it is important for anyone to know that the behavior is
necessarily more complex than it may seem at first glance. Note here
the pyhtonic philosophy that complex is still much better than
complicated. Overall the scrollwheel feature is a massive improvment
over 12.04 LTS and I would like to see it mature to perfection.
To manage notifications about this bug go to:
https://bugs.launchpad.net/unity/+bug/1286784/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
