n+1st report about arrow keys in krunner

[Jacopo De Simoi]

> On 8 March 2010 01:42, Aaron J. Seigo <aseigo at kde.org> wrote:
> 
> > this reminds me about jokes about the difference between theory and
> > practice.
> >
> > if we remove the history then we'll get to deal with tons of bug reports
> > about
> > how you can't do "alt+f2, up arrow, enter" which is a very, very common use
> > pattern.
> >
> > Who says you can't do that? What you *shouldn't* do in this context is
> opening a different list when pressing Up and when pressing Down. You still
> can open the list when you press Up.
> 
>  that theory of "history isn't used" is, in the face of real world practice,
> 
> > dead wrong.
> >
> 
> I dind't mean "history isn't used", I meant "history is not separate from
> bookmarks", which is what the *practical* experiments performed on browser
> history showed.
> 
> 
> 
> >
> > > Every search function
> >
> > krunner is not a search tool. it can be used to search for things, but
> > that's
> > not the extant of its definition.
> >
> 
> If it can be used to search for things, it's a search tool - whether the
> designer wants it this way or not. It's the user who decides what the tool
> does for them, not the programmer. If it has a search function, someone will
> use it for search.

Krunner is a keyboard-based (minicli) interface to the workspace, and it is designed as such.
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.

> 
> If the search tool conflicts with the tool's primary goal, either remove the
> search functionality or make it not conflicting. There's a standard
> interaction for "history+search from a predefined list". I say don't
> reinvent the wheel, use the existing expected interface - or turn it into
> something other than history+search.

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...

__J