Hi, Just a little note to lt you know that I have been able to build discover on my debian-stable (outside Neon) and, given some files copying, I've been able to reproduce the issue I want to look at. (took me a few nights of compilation and (debian) dependencies tracking though :-) )
Could one send a few congratulations to the people who have improved kdesrc-build ? A year or more ago I've tried to build things on debian stable and had to give up after three days because it didn't work. Now it does and that's *very* nice (and impressive). stF On vendredi 10 avril 2020 8 h 59 min 29 s CEST S. Champailler wrote: > 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
