dx-packages team mailing list archive

[Christopher Townsend <christopher.townsend@xxxxxxxxxxxxx>]

Ok, I reviewed and tested the patch and it looks good to me.  I created
a branch and merge proposal to get some other eyes to look at this and
then get it into Unity.

Thanks again for your contribution!

** Changed in: unity
       Status: New => In Progress

** Changed in: unity
   Importance: Undecided => Medium

** Changed in: unity
     Assignee: (unassigned) => Christopher Townsend (townsend)

** Changed in: unity (Ubuntu)
     Assignee: (unassigned) => Christopher Townsend (townsend)

** Changed in: unity
    Milestone: None => 7.2.0

** Changed in: unity (Ubuntu)
       Status: New => In Progress

** Changed in: unity (Ubuntu)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of DX
Packages, which is subscribed to unity in Ubuntu.
Matching subscriptions: dx-packages
https://bugs.launchpad.net/bugs/1286784

Title:
  Inconsistent scrollwheel launcher behavior for window switching.

Status in Unity:
  In Progress
Status in “unity” package in Ubuntu:
  In Progress

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