Thx for your answer. But I'm afradi I don't fully understand it.

> We do get sorted feeds that at
> the moment we're merging naively.

Ok, that's the I way I understand the problem as well.

> One thing to check first of all is to make sure that the exact
> resource you're fetching is already being provided first at its own
> feed.

Let's have an example. Imagine we have 3 feeds : A,B,C.
In each of these, we have 3 resources : a1, a2, a3; b1,b2,b3; c1,c2,c3. They 
have names and descriptions (separated by a dash; a star indicates when the 
titanium word is present):
 
a1* = TitaddOns - An extension to Titanium
a2* = The titanium engine - lorem ipsum ...
a3 = plasma - lorem ipsum ...
b1 = konqueror - lorem ipsum ...
b2 = mozilla - lorem ipsum ...
b3 = dillo - lorem ipsum ...
c1* = titanium - lorem ipsum ...
c2* = titanium italics - not to confuse with titanium
c3* = titanium black - lorem ipsum ...

The search string in Discover is : "titanium". I assume it's a single word.

I assume the content providers will return : a1, c1, c2, a2, c3 (in no 
particular order; for example a content provider might not sort, may take long 
to answer, etc). Basically, what happened in this step is just a filtering, no 
sorting. I assume that filtering is based on the presence of the search term in 
the name of the resource, or in its description. The filtering is done at the 
provider level because if it wasn't, then we'd have to ask the complete list of 
resources of each content providers which could potentially be a lot.

Now that the filtering as occurred, we can sort by relevancy. That sort is done 
entirely in Discover because "relevancy" makes sense only in the UI of discover.

I define a relevancy score :
- 1 = The search term is the only term in the name
- 2 = The search term is present in the name
- 3 = The search term is present in the description

With that in mind, I sort by descending scores and, if scores are equal, I sort 
alphabetically on names : 

c1* = titanium - lorem ipsum ...
a2* = The titanium engine - lorem ipsum ...
a1* = TitaddOns - An extension to Titanium
c3* = titanium black - lorem ipsum ...
c2* = titanium italics - not to confuse with titanium

All the information needed to do that sort is available in Discover itself.
Now, it's perfectly clear that scores don't answer all the questions. Having 
said that, I get back at your comment :

> One thing to check first of all is to make sure that the exact
> resource you're fetching is already being provided first at its own
> feed.

I don't understand :

- Do you mean that, when the relevancy ordering doesn't discriminate enough, we 
should preserve the order of the contents provider ? c1, a2, a1, c2, c3 ?

- do you mean that we should leave the search results grouped by feed and just 
sort the feeds separately : c1,c2,c3,a2,a1 ?

or even something else ?

Again, my point is that discover does the sort, totally irrelevant of how the 
content providers order their stuff...
In that case, I'd look in the ResourcesProxyModel of Discover and order things 
there (with something like the lessThan method).

Thanks for your time :-)

Stéphane




> Le 9 avril 2020 à 22:36, Aleix Pol <aleix...@kde.org> a écrit :
> 
> 
> On Thu, Apr 9, 2020 at 2:49 PM S. Champailler <schampail...@skynet.be> wrote:
> >
> > Hello m-l, Nate,
> >
> > First thanks for the answer, it gives much needed information.
> >
> > I investigated the code further. What Nate says seems
> > to be right. Discover uses a KNewStuff backend, which
> > in turn uses Attica.
> >
> > Now, the thing is, the sorting order is passed from KNewStuff
> > to Attica. As Attica ends up (REST) calling a provider (if I
> > got that well), the sort is done by that provider...
> >
> > So, although we're interested in the sort order which is
> > visible in Discover, the sort is actually done in the
> > providers, far away from Discover.
> >
> > Now, since Discover aggregates results from several providers,
> > I'd say that the responsibility for the sort order must be in
> > Discover since it has to sort and to prioritize the results
> > from the various provider (that is, it's Discover which has
> > to decide what package/theme/newstuff/... is most relevant
> > to the user who started the search).
> >
> > But still the "relevancy" aspect of it stays beyond my
> > understanding. How is that defined ?
> >
> > Does this make sense ?
> >
> > I ask that for two reasons :
> >
> > 1/ it's an indirect way to validate I understand the way
> >    Discover works
> > 2/ I make sure I won't change things that will lead to
> >    architectural dead ends... (I love to give some time
> >    to KDE, but that time is not exactly plenty :-) )
> >
> > Thanks !
> >
> > Stéphane
> >
> >
> >
> > > Le 8 avril 2020 à 18:07, Nate Graham <n...@kde.org> a écrit :
> > >
> > >
> > > See https://bugs.kde.org/show_bug.cgi?id=407588. This was supposed to
> > > have been fixed in AppStream itself, at least for apps. And I can
> > > confirm the fix with the latest version of APpStream--again, at least
> > > for apps.
> > >
> > > However I can see that the problem is still present for non-apps, such
> > > as the "Titanium" GTK2 theme, where I can reproduce the issue, as you
> > > indicate. Looks like the sorting may need to be adjusted in the KNS
> > > backend specifically, or elsein the KNewStuff framework itself.
> > >
> > > Nate
> > >
> > >
> > >
> > > On 4/8/20 3:10 AM, S. Champailler wrote:
> > > > Hello Aleix, hello KDE dev's, <mailto:aleix...@kde.org>
> > > >
> > > > I wanted to modify Discover a bit. Here's the thing :
> > > >
> > > > In KDE Neon, I run Discover. I search for a package named "Titanium".
> > > > The result list has Titanium and some other packages in it (which is
> > > > fine). However, the first item in that list is not named Titanium at all
> > > > (I guess it's a match based, say, on the description).
> > > >
> > > > I'd like to modify the sort order so that if a package has an exact name
> > > > match, then it appears on top of the search results.
> > > >
> > > > I've already looked at the code (and built it !)) and seen that the
> > > > current sort is determined by the m_sortByRelevancy boolean. It seems to
> > > > me that when that boolean is True, then no specific sort happens; not
> > > > 100% sure.
> > > >
> > > > Before going any further, I'd like to make sure my idea doesn't
> > > > contradict some of the initial design of Discover. So, does it ?
> > > >
> > > > Best regards,
> > > >
> > > > Stéphane
> > >
> 
> Hi,
> Yes, your assessment makes sense. It could make sense to better sort
> the different feeds as we receive them. We do get sorted feeds that at
> the moment we're merging naively.
> 
> One thing to check first of all is to make sure that the exact
> resource you're fetching is already being provided first at its own
> feed. If that's not the case this would be something to address first.
> 
> If it's first but gets buried down, we should look into it, I'd
> happily help you there.
> 
> Cheers!
> Aleix

Reply via email to