SoK idea: Improve krunner result displaying and navigation.

[Luiz Romário Santana Rios]

2011/4/28 Aaron J. Seigo <aseigo at kde.org>

> On Thursday, April 28, 2011 09:15:08 Luiz Romário Santana Rios wrote:
> > Currently, when we type something in, krunner displays the results as it
> > finds it, without giving a feedback of whether it is searching or just
> > didn't find anything.
>
> that would be a nice addition.
>
> > It also does not separate the results into its different categories
>
> that's because they are organized by relevance. if they are sorted into
> categories, and if there are 4 categories that match and 5 items in each
> category then the best match from the 4th category will be the 16th item in
> the list(!) even though it is more likely to be what the user wants than
> most
> of the items above it.
>
> i have yet to see a solution for this problem, but am open to such a
> solution
> being offered.
>

Well, I thought about showing only the most relevant results for each
category and priorizing the category with the most relevant results. If a
user want to see more results for that category, they would just need to
expand it. I'll do some mockups for that and will post here.


>
> > and shows some irrelevant results.
>
> by definition, that is not possible. the results are precisely what the
> runners say match. if the results are not relevant, the runner at fault
> should
> be improved.
>

Well, yes, but sometimes I'm looking for a file and a ton of Nepomuk stuff
get in the way, for example. That may a problem with the runner, though.

But what I mean is that, sometimes, the exact match is not the most relevant
result.


>
> > My idea is to give the user a better feedback of what's happening,
> telling
> > them that krunner is searching or that it didn't find anything about
> those
> > terms.
>
> would be nice, yes :)
>

I think krunner should, first, just execute the command by default, just
showing the textbox, and, then, if the user waits a few seconds, all the
runner results would start to show up. Also, if the user just stands in the
front of krunner doing nothing, it would be nice to popup a "Type a command
or a keyword" text.


>
> > Also, the results will be separated into different categories, say,
> > programs, files and folders, Nepomuk tags, etc., giving the user the
> ability
> > of choosing which one of these categories they want to prefer or defer
> and
> > which one of these will contain the default action.
> >
> > I also intend to make it possible for the user to navigate through the
> > results using the arrow keys, instead of tabbing,
>
> you already can. :) as long as the user has not been using the arrow keys
> to
> back into the history, then you can just hit the down arrow to start going
> through the entries.
>

Doesn't work for me. Is this in 4.6 or "trunk"?


>
> > and to show a scrollbar
> > instead of an arrow when there's a lot of results (or maybe a "More"
> > button),
>
> i'd prefer a more button. a scroll bar will ruin the visuals.
>
> > also shrinking the less relevant results.
>
> shouldn't matter as they are already lower in the list?
>

Saving space for more results is one reason to do that.


>
> > Is this a good SoK idea? Is it too little?
>
> it might be too little, yes. but there is a ton of stuff that can be done
> in
> krunner, so a krunner focussed SoK that starts with the above would be just
> fine imho.
>

Maybe I should already start looking krunner's code, so I can see what else
should be done.


>
> > I also thought of a simpler K menu that can run runners in its search,
> > letting you put the results in the favorites just by dragging.
>
> kickoff lets you do this, as does lancelot.
>

If kickoff does, it does not work here. But, yes, I just checked lancelot
and it really does.


>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>


-- 
Luiz Romário Santana Rios
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20110429/67955eb2/attachment.htm