Version: (using Devel) Installed from: Compiled sources Currently in krunner, each result is shown as a single large sized icon with a text description of the icon underneath. This seems fine when the text descriptions are short e.g. kmail, thunderbird, kbiff as results. However, I think this really hurts usability for more interesting uses of krunner. For example, let's say we allow a new command like: play mozart When krunner sees this, it can ask, say, amarok for a list of all songs which have the word mozart in the title/artist. If we then use the icon grid as it is for the results, there just isn't any room to show the full song title name. If the user can only partially remember the artist/song name, they need this data to pick the result. Forcing the user to tab through all the results is incredibly cumbersome and inefficient. There are a few solutions I can think of: * stick to the grid layout but just give each result a box with more horizontal space with the icon on the left i.e. Results ------------------------- ------------------------- | **** Mozart | | **** Mozart | | icon Song 1 | | icon Song 2 | | **** | | **** | ------------------------| ------------------------| ... * Use a single row vertical table i.e. Results ---------------------------------------------------| | **** Mozart | | icon Song 1 | | **** | ---------------------------------------------------| ---------------------------------------------------| | **** Mozart | | icon Song 2 | | **** | ---------------------------------------------------| This might look similar to the current "add widget" dialog box for plasma. I find the second option massively better. We now have lots of room for album name, title, year, album art etc. There's also no reason why krunner cannot take up most of the screen (instead of just a small box, use 90% of the screen space showing results). As we tend to want to stick to about 7 results in the list max for usability reasons, I think a fullscreen krunner in the table form would be excellent. This also means we can select the result using only the up/down arrows with no need for left/right movement. If the history results were integrated into the table, we could then just start krunner, type the command and then simply use up/down to select results without the need for cumbersome tabbing between the edit box and the grid because of the clash caused by the use of left/right arrows.
I just say this example today. The user is looking to email a person whose name starts with "korn". The user is forced to select the "mail to ko..." option to read what the full description is as the full person's name cannot fit into the box: http://polishlinux.org/reviews/kde-4-rev-811151/kde4_811150_krunner_book.jpg If you had more room, you could also display more information about the person (e.g. organisation, email address).
Seems to reporter is focusing on the preview and missing the full text version just above. The report is invalid as the text is already visible, and asking for full text under each icon will not add to clarity but will contribute to information overload.
I don't think you understand the issue I'm reporting as your reply does not address the issues I brought up. I'm aware that the "full text version" is visible near the top of the window but the user is required to select an icon to see this first which takes a significant amount of time compared to skimming the text on the screen. Imagine there were 3 or more icons that were called "Mail to <person's name here>" like the selected icon from this screenshot: http://polishlinux.org/reviews/kde-4-rev-811151/kde4_811150_krunner_book.jpg On each icon preview, you would only see "Mail to <2 characters>" and the rest would be cut off. The user is then forced to cycle through each icon to see the rest of the title to find the person they want to mail. I'm aware of information overload, but in my opinion, too much information is being hidden here, forcing the user to select icons to see the information they want to see. In the mail example, seeing the full text under each icon does add clarity as, at the moment, all the icons look the same and short text previews are almost all the same except for two characters! Imagine you were to search for your emails by subject name and, instead of the usual table of full matching subject names you would get in kmail, you just got a small icon box for each email with the first 20 characters or so of the subject. That just isn't useful and does not aid searching. Look at the details google search results go into and yet users are very productive while using it. My music example above also shows where more information helps.
i highly doubt i'll implement the solution as suggested. i agree we need to show more context on search returns, but i don't really like the precise solution suggested.
And I'd say that is this is a wish, rather than a bug, because it contains a suggestion of feature expansion.
Another example of the flaw in the current implementation (look at the PowerDevil section): http://agateau.wordpress.com/2008/12/16/krunner-is-more-powerful-than-it-looks/ Here, four actions have been found that do very different things, yet the user cannot tell what each icon will do without selecting each icon and reading the full-text as the short description is only big enough for the word "Power..." or "Suspend...". What problems do people have with the solutions suggested in my OP? I really don't understand why krunner's presentation should be much different from what you get when e.g. using google or google suggest (where the search results update after each key press). What logic is behind only showing 8 characters of the search results? It severely limits the ease of use of krunner in my opinion.
I stumbled upon this while preparing to request "list based results view with 16x16 or 22x22 icons and text to right" and I think that, if anything, the problem has been understated. As it is, I've been using KHotKeys and a GTK+ app called gmrun because the "text below icons" layout and the momentary freeze on initial retrieval of results (reported in another bug) make command-mode KRunner not worth the hassle for me. (I have a history of choosing commandline-like UIs when I have to pick between them and useful action providers. My disinterest in Katapult for KDE 3.5 being one example) Compared to some of the alternatives I've tried over the years (including Launchy fairly recently), this is almost perfect, but the only thing I value more than the presentation of results is responsiveness. (Aside from this I really like both the look and the extensibility of KRunner) Probably best to offer users a choice between single-row-per-result listview (what I want) and multi-row-per-result listview (what the bug's initial reports seems to be asking for with his diagrams)
I've just tried KDE 4.2 (it's great!) but the krunner interface has not changed much with respect to this bug. You still can barely read any of the results and having to tab back and forth to look at and select results is very clumsy; using up and down when the input bar retains focus would be easier IMHO. I tried the new quick silver interface. It's slightly better but has issues: 1) selecting results and reading the text is much easier. The horizontal icon cover-flow style presentation with the vertical text list doesn't work well though in my opinion as it's confusing how they relate (i.e. why is the relevant text not next to its icon?). They would have been better stealing the box-switch or cover-switch window switching interface where result text and icons are kept together. 2) I'm confused why you need to press enter twice to launch commands. I'm used to it now but it seemed like an obvious flaw in ease of use as the first selection just seems to hide some results with no benefit. Overall, I'm just confused why an interface like google, window switching etc. is just copied for this. krunner doesn't seem to present any new problems in the domain of navigating search results so it seems that the current best solutions should be emulated. The run menu interface from KDE 3.5 is fine even; just add some icons and text descriptions to the drop-down box.
With the release of KDE 4.3 the results are, in fact, presented in rows. That solves the initial request of this bug. If you still have some other complaints about Quicksilver, please open a new bug report.