Review Request 117447: Runner - QueryMatch: Allow each match to give a category

[Aleix Pol Gonzalez]

> On April 9, 2014, 11:27 a.m., Marco Martin wrote:
> > I like the idea, only two things:
> > * I am not sure about the default, would rather have it empty so everybody that doesn't set it goes in a "misc" section
> > * if this goes in, i would like to see sprinter's querymatch have the same, to avoid "oh crap" moments when porting
> 
> Marco Martin wrote:
>     (is pretty much corresponding to matchtype in sprinter if i understood correctly?)
> 
> Aleix Pol Gonzalez wrote:
>     About the default, we discussed it a bit shortly and it seems like runners are _never_ sharing categories. If we haven't found a use-case yet, I wouldn't expect it to happen now.
>     
>     Creating a shared misc category sounds artificial to me.
>
> 
> Marco Martin wrote:
>     uhm, i can easily think about different runners returning website urls, or resutls of type "video" regardless if is a search on the filesystem or from a youtube runner..
> 
> Vishesh Handa wrote:
>     * I like the idea of having a sensible default. A Misc section sounds ugly. Plus this means we only need to patch a few runners (services and Baloo)
>     
>     Sprinter has a MatchType which is an enum. I tried doing the same thing originally but I could not figure out how how to map most of the runners we have - Solid / Recent Documents / Places / etc. When someone decides to write a UI for Sprinter, they will encounter the same issue. They currently group "Recent Documents" as "Files", and "Places" as "FileSystemLocation".
>     
>     @Marco: I do not think that the "Youtube" videos should be grouped under the same "Videos" category for the videos files in your filesystem. We need to give some distinction between local videos and external videos.
> 
> Marco Martin wrote:
>     hmm, to me a video is a video..
>     
>     by default all the remote queries should of course be disabled, but if i explicitly enabled them, then i don't care where the video comes from.. i would probably care having all local videos coming before the remote ones, but they are still just videos
> 
> Vishesh Handa wrote:
>     Yes they are all just videos, but the user needs to be given context as to where the data comes from. One cannot just interleave youtube videos + vimeo videos + local videos. 
>     
>     We also have to take our UI into consideration - We can at max display 3-6 results of each category[1]. If we interleave web searches + local searches, then the web-searches will almost never be shown.  The local results will be faster than the web results.
>     
>     [1] depends on the number of categories

Maybe we should have a discussion separately regarding remote vs local? I think it hasn't been discussed and I'm afraid it would cause misunderstandings in the future.

Regarding the actual patch, I don't think it would be bad to have a "YouTube" category.


- Aleix


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117447/#review55272
-----------------------------------------------------------


On April 9, 2014, 11:18 a.m., Vishesh Handa wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117447/
> -----------------------------------------------------------
> 
> (Updated April 9, 2014, 11:18 a.m.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Repository: krunner
> 
> 
> Description
> -------
> 
> 
>     This string based category is useful in categorizing the results. By
>     default the category defaults to the name of the runner.
> 
> 
> Diffs
> -----
> 
>   src/querymatch.h afec76e 
>   src/querymatch.cpp 83888f7 
> 
> Diff: https://git.reviewboard.kde.org/r/117447/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140410/8e6d3c5d/attachment.html>