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

Thu Apr 10 11:13:10 UTC 2014

> 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
> 
> Aleix Pol Gonzalez wrote:
>     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.
> 
> Marco Martin wrote:
>     only thing i fear about having categories as strings is the complete lack of standardization, that will bring things like categories
>     "pictures" "images" "photos"
>     "music" "audio" "mp3" "songs"
>     "remote" "internet" "cloud" "services" "online"
>     I would really prefer as few categories as possible even if not "technically precise" than a load of random names each author of a runner came up, each one different
>
> 
> Emmanuel Pescosta wrote:
>     In Sprinter you can define the type and the source of each match.
>     
>     e.g. youtube sprinter-plugin:
>        Sprinter::QueryMatch match;
>        match.setTitle(tr("%1 (%2, %3)").arg(title, author, time));
>        match.setType(Sprinter::QuerySession::VideoType);
>        match.setSource(Sprinter::QuerySession::FromNetworkService);
>     
>     And I completely agree with Marco, a video is a video independent from the source it comes from.
> 
> Marco Martin wrote:
>     about having too many results per category..
>     this is clearly a visualization issue more than a model related one.
>     
>     one solution may be (given that each category has a really reliable prioritization of results) to show a max of results per category, say 10 or so, plus a "more" item as the last, and then it goes in a second page where it shows all the results for a given category, and only that category.
>     or i don't know, there may be other ;)

Regarding Standardization - We have a limited number of runners, most of which currently do NOT require categories.

Regarding this patch: We can either have this simple category implementation or implement all of this type + source + others which Sprinter provides. Considering that KRunner is going to be deprecated, I rather not do that. Additionally it will make the Milou code quite complicated as well.

- Vishesh

-----------------------------------------------------------
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/1fb5f968/attachment.html>