n+1st report about arrow keys in krunner

Diego Moya turingt at gmail.com
Tue Mar 9 10:21:43 CET 2010


On 8 March 2010 23:39, Jacopo De Simoi wrote:

> This also definitely implies that it can be used as a search facility, it's
> not its main purpose but it does not necessarily conflict with the primary
> goal; in fact I find it a very useful tool.
>

 I agree with that. It's not the search function that conflicts with the
primary function as a launcher, it's the search *interface.*


The issue here is imo the fact that the examples of 'history+search from a
> predefined list' you are taking  do not refer to a history of queries (such
> as krunner history), but rather to a history of results (such as firefox
> history).
> This complicate things quite a bit, since there's not anymore a one to one
> correspondence between history elements and results, but each history
> elements provides in principle a number of different results.
> I am not able to see how they should apply to our case, unless we are
> willing to implement krunner history as an history of "recent results"
> rather than "recent queries". Whether we should or not, I guess it's open to
> discussion...
>
>
I'm not asking for a change in functionality. I'm arguing for a change in
presentation. Having separate interfaces for retrieving previous queries and
for selecting launcher items does cause interaction problems, as shown by
the issues in this thread.

The solution I'm arguing for is disabling the auto-complete history feature
provided by the combo box, because the interaction style provided by the
widget is conflicting with the rest of the application. This means
reimplementing exactly the same functionality in the main list, showing
previous queries together with applications that both match the new typed
search string. You could show recent queries at the bottom of the list -
this way pressing Up wraps around the list and places you  at the bottom,
right on the most recent query, while pressing Down places you on the first
search result. Same functionality, same keys, a much simpler interface.

It's sad that standard widgets functions can't always be reused, but this
time it's necessary for a smooth integration - the existing code for query
history is not providing a good interface and is inducing user errors, so
IMHO it shouldn't be used in this case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100309/42bb16f0/attachment-0001.htm 


More information about the Plasma-devel mailing list