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.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
