Using mouse scrollwheel on unfocused/inactive Launcher icons should not focus that app

Bug #1267888 reported by Christopher Townsend
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Unity
Fix Released
Medium
Christopher Townsend
unity (Ubuntu)
Fix Released
Medium
Christopher Townsend

Bug Description

In bug #1081843, the following design was given:

"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."

However, a community member recently brought up the issue that this is not expected behavior and posted as such in that bug. Mark Shuttleworth then responded that that design is a mistake and that nothing should happen when using the mouse scroll wheel over a Launcher icon of an unfocused app, no matter how many windows are associated with it.

This bug is to fix that design.

Related branches

Changed in unity:
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Christopher Townsend (townsend)
milestone: none → 7.2.0
Changed in unity (Ubuntu):
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Christopher Townsend (townsend)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

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

Changed in unity:
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (18.5 KiB)

This bug was fixed in the package unity - 7.1.2+14.04.20140214.1-0ubuntu1

---------------
unity (7.1.2+14.04.20140214.1-0ubuntu1) trusty; urgency=low

  [ Sebastien Bacher ]
  * use unity-control-center by default.
  * lists keybinding in unity-control-center. (LP: #1271710)

  [ Brandon Schaefer ]
  * Bump to new libnux from this branch:
    https://code.launchpad.net/~brandontschaefer/nux/xim-preedit-
    support.
  * Adds Super+L to lock the screen, while keeping the older shortcut
    around in g-s-d (Ctrl+Alt+L). (LP: #830709)
  * Do not open the dash/hud on a monitor with a top most window that is
    fullscreen. (LP: #1267210)
  * Implement an EMConveter. This way with default settings such that
    DPI = 96.0f, and font_size = system font size. We can get the
    correct EM value for any pixel size. Once we have the correct EM
    value for any pixel size, the DPI value can be adjusted to the
    current logical one. From here, you can now get the correct pixel
    size based from of the EM value for the logical DPI of the screen.
  * Refactor EMConverter API. Now all thats needed is int
    ConvertPixels(int pixel); This will calculate the correct pixel size
    based on the DPI and font size.
  * Testing that the ibus anthy tests could possibly be causing strange
    issues on the nvidia machine. So skipping them to test if tihs is
    the source of the error.
  * Add Pt to Px function to em converter.
  * Move EMConverter over to unity settings.
  * Add multi monitor support for EMConverter in unity settings. Now you
    can grab a specific converter per monitor.
  * Simple RawPixel class. It adds 2 define literals, ex: 10_em,
    10.0_em. From there it turns them into raw pixels. RawPixels have CP
    (CovertPixel) function which takes in an EMConverter that allows you
    to use a converter specific to a monitor to convert the raw pixel to
    the correct value.

  [ Marco Trevisan (Treviño) ]
  * Don't re-present all of our windows on every frame. Only do that if
    damage intersects it. Use the new APIs exposed by compiz and nux to
    intelligently determine which windows need to be presented per-frame
    and only register damage for those windows. This fixes two things:
    1. BaseWindows being redrawn from scratch every time damage was
    registered over them. That was incorrect and should only be done in
    the case of background blurs. 2. BaseWindows being drawn to the
    screen on every frame, regardless of whether or not they needed to
    be. Now they will only be drawn if some damage intersects beneath
    them. Note that unity will expand the damage region to accomadate
    the base window since nux does not support geometry clipping. So if
    there is a partial intersection of the launcher for example, the
    area of the screen which contains the launcher will be re-painted
    (but the launcher itself won't be redrawn, just its texture) (LP:
    #1080947). (LP: #1080947)
  * Convert compiz regions / rects to nux::Geometry's and back easily.
  * UnityScreen: remove the useless and expensive gl{Push,Pop}Attrib
    calls For some reasons this code was copied by the opengl plugin as
    a workaround to fix the s...

Changed in unity (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
florin (florin-arjocu) wrote :

If I understand it correctly, if I am using Firefox and I also have 3 open windows with Nautilus, for changing to one of the 3 windows of Nautilus, I have to one click and then scroll on the Launcher icon. It was nicer just to scroll, without the click. It is faster and I really like this interaction, too bad it is removed.

Revision history for this message
florin (florin-arjocu) wrote :

As I do not use a mouse (I use only the touchpad), I got used to scroll even if I have one window. It is so nice and fast, I see it as a feature, not a bug. Maybe it is better if this comes as an option (tick) in Appearance settings, who wants it could activate or deactivate it.

Revision history for this message
Christopher Townsend (townsend) wrote :

Hi florin,

No, this change is only when you have one window of an application open and then move the cursor over the Launcher icon and scroll. The old behavior was to focus the window if it's unfocused. It does not affect applications with more than one window open.

The problem is, when a user scrolls in one direction, there is an expectation that scrolling in the opposite direction will put you back in the former state. However, trying to save which application window was last focused is not something we need to do at this time. But I understand that some users have gotten used to this behavior, so we are looking in to adding a setting to restore the old behavior.

Thanks!

Revision history for this message
asmoore82 (asmoore82) wrote :

"so we are looking in to adding a setting to restore the old behavior."

I only regret that I have but 2 thumbs to put up for this option.

Revision history for this message
Stephen M. Webb (bregma) wrote :

Fix Released in Unity Unity 7.2.0.

Changed in unity:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.