n+1st report about arrow keys in krunner

[Diego Moya]

On 9 March 2010 17:54, Aaron J. Seigo wrote:

regardless, there are ways of doing the keyboard interaction with the
> current
> set of widgets that will work. i'm not interested in breaking the history
> feature on those who use it and rely on it just to reach some search-tool-
> purity.
>

Neither do I - I'm interesting in fixing the history feature for those users
who filed bug reports because of the confusing interface, not in removing
the feature or altering the valid workflows.


>
> and let me say it one more time: krunner is not a search tool.
> and again: krunner is not a search tool.
>

Half the meanings of a software product are provided by the user when trying
to make sense of the interface.
The designer doesn't decide what the tool is used for. The designer doesn't
decide what the tool is used for.
I know how to repeat myself too. ;-)

(Besides,  the krunner page at Userbase disagrees with you):
http://userbase.kde.org/Tutorials/Krunner

"Krunner is tool for searching and launching files and applications..."



> what is it then? it is the evolution of kde2/3's "run command" dialog. and
> that use case must still be preserved.
>
>

Again, I'm not trying to change the use cases and turning krunner into a
general desktop-wide search - I use Lancelot for that. I'm trying to provide
a better interaction for the existing user case, one that doesn't create two
different lists depending on the key you press (Tab or arrows) and the state
from which you start (empty box or some characters already typed, though
this criteria could be used if both lists can't be integrated into one).

This should improve learnability - people wouldn't need to be told that "Tab
changes focus to the results list" after they try to use the down arrow and
it doesn't work as expected. The whole point of this thread as I see it is
that the user shouldn't use different keys for the history and result lists
-  they should be used exactly the same, either if both lists are merged or
if we have a "history only" list (when the text box is empty) and a "results
only" one (when typing).




> On March 9, 2010, Diego Moya wrote:
> > reimplementing exactly the same functionality in the main list, showing
> > previous queries together with applications that both match the new typed
> > search string.
>
> the whole point of history is so you don't have to type. if you have to
> type
> to match the history, then there's no point in having the history, is
> there?
>

There's one, auto-complete. Right now you type "ama"... and the box field
suggests ..."rok", which you should get completed with the Tab key. But this
can be sacrificed if filtering history results is too hard to develop -
showing the history list only when the text box is empty would be a good
compromise solution.



 one compelling suggestion i've seen is to put the last N selected items in
> the
> listing by default when shown. this was meant to augment the history not
> replace it, and won't work nicely with an always-shown krunner, but it is
> an
> interesting idea.
>

I'd suggest showing the last N history items when you press Up or Down keys
when the textfield in empty, or maybe as soon as krunner gets focus. This
would also work for the case when krunner is always shown.


moreover, if history is shown below then we'd either show only the match
> that
> was actually activated (a possibility, but also a significant change in
> behaviour) or it becomes a two step process where the first step is "select
> the history match" which would then cause another run against it and then
> "select the match that matches the history match" once the returns are
> made.
>

Does the current textbox's history not filter already by the typed prefix?
I'll have to check it this afternoon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100310/bc6a989c/attachment.htm