Bug 222610 - krunner shows too many suggestions
Summary: krunner shows too many suggestions
Status: RESOLVED FIXED
Alias: None
Product: krunner
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-13 22:57 UTC by Alexander Neundorf
Modified: 2015-02-04 17:15 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
krunner showing yast 3 times (90.08 KB, image/png)
2010-01-13 22:59 UTC, Alexander Neundorf
Details
Having typed "digi" in krunner (22.51 KB, image/jpeg)
2010-01-15 19:17 UTC, Alexander Neundorf
Details
Having typed "digik", krunner now suggests "digikam" (15.89 KB, image/jpeg)
2010-01-15 19:18 UTC, Alexander Neundorf
Details
Accepted the autocompletion, digikam is now there twice. (16.60 KB, image/jpeg)
2010-01-15 19:18 UTC, Alexander Neundorf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Neundorf 2010-01-13 22:57:56 UTC
Version:            (using KDE 4.3.1)
OS:                Linux
Installed from:    openSUSE RPMs

When I enter the name of a program which I want to start in krunner, it almost always shows me multiple time the same program.
I guess once for the executable it found, once for the desktop file it found, and maybe once more.
E.g. yast under SUSE appears 3 times.

This is confusing, I guess for somebody who doesn't know what's going on even more than for me.

Alex
Comment 1 Alexander Neundorf 2010-01-13 22:59:06 UTC
Created attachment 39858 [details]
krunner showing yast 3 times
Comment 2 Jacopo De Simoi 2010-01-15 14:03:45 UTC
Two results are by default: 
One is the application given by the "application" runner which parses .desktop files, the other is the shell command runner which find an executable named yast.
The third one seems to be the yast kcm (is there such a thing?). In this case you might want to file a bug to suse in order for them to make sure that the .desktop file contains meaningful values which allow to properly discern between them
Comment 3 Alexander Neundorf 2010-01-15 18:40:51 UTC
Could krunner be so clever, that if it finds a desktop file which contains /usr/bin/foo, and if it additionally found the executable /usr/bin/foo, to show only one of them, probably the desktop file one ?
As a user I don't care that the result is delivered by two different runners, it is just confusing to see the same thing multiple times.

Alex
Comment 4 Jacopo De Simoi 2010-01-15 18:52:20 UTC
(In reply to comment #3)
> Could krunner be so clever, that if it finds a desktop file which contains
> /usr/bin/foo, and if it additionally found the executable /usr/bin/foo, to show
> only one of them, probably the desktop file one ?

not atm, runners should not know of each other's results.

> As a user I don't care that the result is delivered by two different runners,
> it is just confusing to see the same thing multiple times.

I perfectly understand this point; the only clean solution would be to merge the application and shell runners togheter, but I'm not sure this would be a good idea.
Although let me point out that the shell runner requires you to write the *full* executable name, hence this issue is really a problem only for short named executables such as yast.

As a side note, I am thinking about some fix (for 4.5) for distinguishing KCM modules from applications to avoid having to rely on someone else's good sense when compiling/translating the .desktop files. 
Namely we should add a "configure" emblem to overlay icons related to KCM with.
What do you think about this?
Comment 5 Alexander Neundorf 2010-01-15 19:17:01 UTC
> not atm, runners should not know of each other's results.

I understand that idea completely from a developers POV.
Still from a users POV the same executable with the same flags shouldn't appear twice. Maybe they could also somehow return the full command which would be executed, and krunner could check those results for duplicates ?

> *full* executable name, hence this issue is really a problem only for short
> named executables such as yast.

Hmm, depends.
I'm attaching 3 screenshots.
First I typed only "digi". Several suggestions appear, that's ok.
Then I add the "k", gives "digik", now only one suggestion is there, but autocompletion already suggests "digikam".
If I now accept the autocompletion by pressing the End-key, I have the full name there and get digikam now twice.
So, at least for me it's the normal case to see everything twice.

Alex
Comment 6 Alexander Neundorf 2010-01-15 19:17:40 UTC
Created attachment 39917 [details]
Having typed "digi" in krunner
Comment 7 Alexander Neundorf 2010-01-15 19:18:13 UTC
Created attachment 39918 [details]
Having typed "digik", krunner now suggests "digikam"
Comment 8 Alexander Neundorf 2010-01-15 19:18:46 UTC
Created attachment 39919 [details]
Accepted the autocompletion, digikam is now there twice.
Comment 9 Jacopo De Simoi 2010-01-15 19:45:38 UTC
> > not atm, runners should not know of each other's results.
> I understand that idea completely from a developers POV.

Yes, I was speaking to you as a developer, explaining why this is not possible at the moment. This was by no means an excuse for the behavior ;)

> Maybe they could also somehow return the full command which would be
> executed, and krunner could check those results for duplicates ?

This might be an option. 
However, there is the following usecase: suppose that I want to run digikam and see the debug output in a terminal; how would I do that without the dedicated shell runner? it wouldn't make much sense to have an option for that for the services runner.

> If I now accept the autocompletion by pressing the End-key, I have the full
> name there and get digikam now twice.

Yeah, accepting the autocompletion is equivalent to full-typing; but my point is that you can just run digikam before accepting the autocompletion by just hitting enter, which is what we expect most users do.

> So, at least for me it's the normal case to see everything twice.
:(

I suggest you to open a discussion about this issue on the plasma-devel mailing list since obtaining some sort of fix for this involve quite substantial API addition.
Thanks a lot
Comment 10 Beat Wolf 2010-01-16 12:30:05 UTC
what about each runner returning a "unique" hash/identifier for the command that is going to be exectued? Then all you have to make is make sure that for exmple the application and the shell runner return indeed the same id if the command is the same, so that you can then filter the duplicates in the krunner. Sounds doable on paper at least :)
Comment 11 Dennis Schridde 2013-01-15 14:44:30 UTC
(In reply to comment #9)
> > Maybe they could also somehow return the full command which would be
> > executed, and krunner could check those results for duplicates ?
> 
> This might be an option. 
> However, there is the following usecase: suppose that I want to run digikam
> and see the debug output in a terminal; how would I do that without the
> dedicated shell runner? it wouldn't make much sense to have an option for
> that for the services runner.
See bug #313301 where I request customisable trigger-words for each runner. That would allow a "power-user" to explicitly select a specific runner - e.g. if he actually wants to run something in the shell.

I also suggest the runners to inform krunner about the action they intend to execute, if they were selected. Something like tuple of (type, path), e.g. (execute, /usr/bin/ls), (open, ~/Documents/MyDoc.txt), ...
Comment 12 Vishesh Handa 2015-02-04 17:15:54 UTC
I'm marking this bug as fixed with Plasma 5. We're now grouping the results and showing additional information.