<div class="gmail_quote">On 9 March 2010 17:54, Aaron J. Seigo wrote:<br><div><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
regardless, there are ways of doing the keyboard interaction with the
current<br>
set of widgets that will work. i'm not interested in breaking the
history<br>
feature on those who use it and rely on it just to reach some
search-tool-<br>
purity.<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
and let me say it one more time: krunner is not a search tool.<br>
and again: krunner is not a search tool.<br></blockquote><br>Half
the meanings of a software product are provided by the user when trying
to make sense of the interface.<br>The designer doesn't decide what the tool is used for. The designer doesn't decide what the tool is used for.<br>I know how to repeat myself too. ;-)<br><br>(Besides,
the krunner page at Userbase disagrees with you):<br><a href="http://userbase.kde.org/Tutorials/Krunner" target="_blank">http://userbase.kde.org/Tutorials/Krunner</a><br><br>"Krunner
is tool for searching and launching files and applications..."<br><br><br><div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
what is it then? it is the evolution of kde2/3's "run command" dialog.
and<br>
that use case must still be preserved.<br><div> </div></blockquote><br>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).<br><br>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).<br><br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On March 9, 2010, Diego Moya wrote:<br>
> reimplementing exactly the same functionality in the main list, showing<br>
> previous queries together with applications that both match the new typed<br>
> search string.<br>
<br>
</div>the whole point of history is so you don't have to type. if you have to type<br>
to match the history, then there's no point in having the history, is there?<br></blockquote><div><br>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.<br>
<br><br><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
one compelling suggestion i've seen is to put the last N selected items
in the<br>
listing by default when shown. this was meant to augment the history not<br>
replace it, and won't work nicely with an always-shown krunner, but it
is an<br>
interesting idea.<br></blockquote><br>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.<br><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
moreover, if history is shown below then we'd either show only the match that<br>
was actually activated (a possibility, but also a significant change in<br>
behaviour) or it becomes a two step process where the first step is "select<br>
the history match" which would then cause another run against it and then<br>
"select the match that matches the history match" once the returns are made.<br></blockquote><div><br>Does the current textbox's history not filter already by the typed prefix? I'll have to check it this afternoon.<br>
<br><br></div></div>