Dash waits before letting user press 'enter'

Bug #971130 reported by Alan Pope 🍺🐧🐱 πŸ¦„ on 2012-04-01
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Unity
Confirmed
Undecided
Unassigned

Bug Description

This bug may be the counter to bug 749428 "When we press Enter to run the first search result, Unity should wait until searching is finished". I do not want to wait for search to complete, I can see the results, and the single hit is the one I want. I do not want to have to wait to press enter when I can see the exact match in front of me.

See video:-

http://www.youtube.com/watch?v=BcZ0rU7KMtU

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: unity 5.8.0+bzr2201ubuntu0+677 [origin: LP-PPA-unity-team-staging]
Uname: Linux 3.3.0-030300rc5-generic x86_64
ApportVersion: 2.0-0ubuntu2
Architecture: amd64
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell]
CrashDB: unity
Date: Sun Apr 1 23:18:52 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120203)
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=xterm
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: unity
UpgradeStatus: No upgrade log present (probably fresh install)

Alistair Buxton (a-j-buxton) wrote :

Confirming. I actually thought pressing enter was plain broken, because the searching is so slow to finish.

Changed in unity:
status: New → Confirmed
Dylan McCall (dylanmccall) wrote :

Good point, but let's be careful here :)
Bug #749428 was resolved with some level of agreement, so it would be nice to get the best of both worlds here rather than bouncing between two extremes.

The problem is that search takes too long in some cases, so perhaps Unity could wait for the top results, rather than all of them?

Maybe there could be a timer that starts when searching begins. If the user has been typing for more than one second, there has been enough time to register what is going on, so Unity opens the first (or selected) result no matter what.

Daniel Fett (fett-ubuntu) wrote :

The main argument for waiting until search has finished is, that when I enter "abc" and this has always led to application "abcde" being started, I expect that it always does it. That is, when I enter "abc" and hit enter, Unity should wait for the search and then launch the best-matching hit instead of not waiting for the search and starting "abcxx" just because it was momentarily the best match.

I didn't realise until I read the comment from a-j-buxton that I too thought the enter key was just broken, which is why I use the mouse to start applications.

The length of time search takes is irrelevant. The result the user was looking for has already been found and is displayed on screen as the first hit. The user should be able to choose this without having to wait for a bunch of erroneous search results to appear. Indeed the user _can_ choose it with the mouse, but this means taking the hand off the keyboard and moving it to the mouse to click which is faster than it takes the search to finish in some cases.

The user I recorded the video as on this bug report was a 'clean' user with almost no documents in the home directory. The search returns after a very short period. However when I logon as "me" on the same machine it's considerably worse.

It takes around 5-6 seconds before I can actually press enter after typing "gedit" into the dash. Adding 5 seconds to every application start makes this brand new Thinkpad X220 ( Core i7 / 8GB / 240GB (500MB/s SSD) ) system feel like a Pentium III.

@Daniel, I appreciate there is the opportunity for error if you blindly press enter assuming you'll get the same result. However I am not doing that. I'm sat looking at the screen, waiting until the right result appears. It has appeared and I want to start the application. I don't need to wait for any more results to appear, there is no 'more right' answer to "gedit" than "gedit" (in this case).

tags: added: 5.10-pretesting1
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers