the launcher should start hidding when an icon is clicked

Bug #709178 reported by Sebastien Bacher
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ayatana Design
Fix Released
Undecided
Unassigned
Unity
Fix Released
Low
Didier Roche-Tolomelli
unity (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

Binary package hint: unity

Using unity 3.2.16 on natty on a desktop configuration with the launcher autohidden I find annoying having to wait for the timeout to get the launcher getting off the application you just launched, should the launcher start going away when you click on an icon so you can focus on the application you just started?

Related branches

Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

Seems that you really want to get ride of the 1s delay everywhere :) Maybe it needs some design refinement there.

All what is below assume that the cursor isn't above the launcher to trigger autohide:
Currently, the behavior is:
* Click on Super to trigger the launcher
 a) press the super button for more than one second -> immediately disappear
 b) press the super button for less than one second -> wait for the 1s to terminate, and then disappear

* Hovering the bfb, then moving the mouse away from the launcher:
  wait for 1s to disappear

* Cick on the bfb to open the dash (or any place in the futur), then clicking outside the place to close it or on any item:
  a) the whole operation took more than one second -> immediately disappear
  b) the whole operation took less than one second (very unlikely) -> wait for the 1s to terminate, and then disappear

* Hovering the bfb/launcher, doing anything, and then put the mouse back on the desktop:
  wait for 1s to disappear

* Hovering the bfb/launcher, click on one item, (/!\ the mouse is still above the launcher), then put the mouse back on the desktop:
  wait for 1s to disappear

Changed in unity:
status: New → Incomplete
Changed in unity (Ubuntu):
status: New → Incomplete
Revision history for this message
Sebastien Bacher (seb128) wrote :

> Seems that you really want to get ride of the 1s delay everywhere :) Maybe it needs some design refinement there.

Right, a

Revision history for this message
Sebastien Bacher (seb128) wrote :

> Seems that you really want to get ride of the 1s delay everywhere :) Maybe it needs some design refinement there.

Right, after some time using unity with autohiding I find that having the launcher always on screen worked much better for me, I keep spending my time moving to the corner to get the launcher, click on tasks and wait a few seconds for the launcher to go away from the application I just started (usually firefox, I tend to close and open it rather than using tabs), I should perhaps turn back to option to keep the launcher on screen...

Paul Sladen (sladen)
tags: added: ayatana-design
Revision history for this message
Mark Shuttleworth (sabdfl) wrote : Re: [Bug 709178] Re: the launcher should start hidding when an icon is clicked

Yes, I can confirm that launching an app from the launcher should then
immediately hide the launcher even if the mouse stays over the launcher.
In other words, as a guiding principle, "as soon as we think you are
done with the launcher, it hides". I suspect that guidance would cover
other scenarios as well, like hiding the launcher after picking a new
window from the spread views.

Mark

Changed in ayatana-design:
status: New → Confirmed
Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

@Mark: hiding immediately after you click on a launcher icon and then pull your mouse off the launcher, right? (otherwise, you won't be able to click multiple times on a launcher icon to get the different spread views/filtering…). So, not just on clicking on a launcher icon?

The think is that when you click on a launcher icon and pull your mouse off the launcher and it hides immediately, you won't see the "starting" animation reassuring you that the application is, indeed, starting. But I think it's a fair assumption that if you want to ensure it's starting, just let your mouse hovering the launcher after clicking.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Didier, starting an application and using a dash feature seem different action, it's likely that after starting an application you want to use it where when triggering a dash feature you want to stay in the dash

Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

Sebastien, agree, but at session start, I think most of people want to open maybe two applications from the launcher, so hiding right away after clicking does't seem right. I would suggest : one click/action + mouse off the launcher for this as in my previous post.

In addition, I would suggest for consistency:
* clicking on an item of a quick list: closing immediately the launcher as well.

So, basically the only case where this one second timeout remains is:
* you are hovering the launcher before making any action and you cursor slightly get off the launcher (to have the time to put it back to avoid false positive).
* I would suggest to set back the same kind of behavior (was set in the last release from another bug report) with the super key:
 a/ press <super>, whatever the time you press it and don't do any action: one second delay (to avoid false positive and flickering if you release it wrongly)
 b/ press <super> and do an action either with the mouse or by a shortcut: close the launcher as soon as super is released (as we maybe want to trigger multiple actions).

What do you think?

Revision history for this message
Sebastien Bacher (seb128) wrote :

Counting the click and waiting to move away from the launcher would work indeed

Revision history for this message
Mark Shuttleworth (sabdfl) wrote :

Seb, you're right, we should not hide instantly. However, if the mouse
is inactive for a second, THEN we can hide, even if the mouse is still
in the area where the launcher is.

The effect I'm looking for is that I can go to the launcher, click, and
then let go of the mouse, and the launcher will hide pretty quickly. I
don't want to HAVE to move the mouse off the launcher.

Mark

Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

Ok, let's try that. So to sum up, we have:
* I. you are hovering the launcher:
    a/ before any action:
        1. let the launcher shown as long as the cursor is in the launcher area
        2. you have to get your cursor off the launcher to hide it after 1s delay (to avoid false positives)
    b/ after an action (drag/drop, left/right click):
        1. let your mouse cursor without moving for one sec: hide the launcher
        2. get your mouse off the launcher: hide the launcher immediately
* II. with the super key:
     a/ before any action, have the 1s delay on super key release (to avoid false positives as well)
     b/ after any action with the mouse or with a keyboard shortcut on the launcher: hide the launcher immediately on key release

I'm a little bit afraid that II. b/ 1. can be seen a little bit "too magical" and so puzzling the user (not easy reproducible experience), but we can give it a try :)

Revision history for this message
Mark Shuttleworth (sabdfl) wrote :

Thanks Didrocks this was a great summary!

On 01/02/11 08:28, Didier Roche wrote:
> * II. with the super key:
> a/ before any action, have the 1s delay on super key release (to avoid false positives as well)
> b/ after any action with the mouse or with a keyboard shortcut on the launcher: hide the launcher immediately on key release

I can imagine users launching multiple apps while holding down Super. So
Super+1,2,3 should launch apps 1, 2 and 3, then releasing Super hides
the launcher.

Mark

Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

ok, will get to it as soon as Jason merge his new launcher-reorganization branch :)

Changed in ayatana-design:
status: Confirmed → Fix Released
Changed in unity (Ubuntu):
status: Incomplete → Triaged
importance: Undecided → Low
Changed in unity:
status: Incomplete → Triaged
importance: Undecided → Low
assignee: nobody → Didier Roche (didrocks)
Changed in unity:
milestone: none → 3.4.2
Changed in unity:
status: Triaged → Fix Committed
Changed in unity:
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package unity - 3.4.2-0ubuntu1

---------------
unity (3.4.2-0ubuntu1) natty; urgency=low

  * New upstream release:
    - add --distro switch to remove local installation of unity with default
      options (LP: #715703)
    - global search and speedups in places
    - Using fade effect to cut the window Title when it's longer than the panel
      (LP: #694924)
    - Launcher - Add ability for apps to indicate progress through Launcher icon
      (LP: #676596)
    - calling unity should kill unity-panel-service (LP: #711289)
    - unity places should return a default icon when no matching icon is found
      (LP: #711200)
    - the launcher should start hidding when an icon is clicked (LP: #709178)
    - Highlight drag-friendly Launcher tiles when dragging a file (LP: #607782)
    - Fix migrate_favorites.py crashed with OSError in get_log_file(): [Errno 2]
      No such file or directory: '/home/ubuntu/.local/share/unity' (LP: #711964)
    - places should support wrong Icon= format (with extensions) (LP: #711189)
    - unity crashed with AttributeError in reset_unity_compiz_profile():
      'NoneType' object has no attribute 'get_default_value' (LP: #711105)
    - unity crashed with GError in reset_unity_compiz_profile() (LP: #710876)
    - Middle click on application icon should open a new window (LP: #709707)
    - Launcher - Add interaction to support dragging and dropping behind the
      launcher (LP: #702482)
    - Launcher - Enable dragging and dropping of files & folders to Launcher
      icons (LP: #676549)
    - Launcher - Add number notifier to Launcher icons (LP: #676455)
    - Support dragging files to trash to delete them (LP: #619686)
    - [launcher] Indicator-only applications showing as open applications
      (LP: #703396)
    - Unity does not accept mouse clicks (LP: #683328)
    - dash is empty (LP: #710792)
  * debian/control:
    - depends on latest nux
 -- Didier Roche <email address hidden> Thu, 10 Feb 2011 20:45:47 +0100

Changed in unity (Ubuntu):
status: Triaged → 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.