See https://bugs.kde.org/show_bug.cgi?id=3D407588. This was supposed to=20
have been fixed in AppStream itself, at least for apps. And I can=20
confirm the fix with the latest version of APpStream--again, at least=20
for apps.

However I can see that the problem is still present for non-apps, such=20
as the "Titanium" GTK2 theme, where I can reproduce the issue, as you=20
indicate. Looks like the sorting may need to be adjusted in the KNS=20
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:aleixpol@kde.org>
>=20
> I wanted to modify Discover a bit. Here's the thing :
>=20
> In KDE Neon, I run Discover. I search for a package named "Titanium".=20
> The result list has Titanium and some other packages in it (which is=20
> fine). However, the first item in that list is not named Titanium at all=
=20
> (I guess it's a match based, say, on the description).
>=20
> I'd like to modify the sort order so that if a package has an exact name=
=20
> match, then it appears on top of the search results.
>=20
> I've already looked at the code (and built it !)) and seen that the=20
> current sort is determined by the m_sortByRelevancy boolean. It seems to=
=20
> me that when that boolean is True, then no specific sort happens; not=20
> 100% sure.
>=20
> Before going any further, I'd like to make sure my idea doesn't=20
> contradict some of the initial design of Discover. So, does it ?
>=20
> Best regards,
>=20
> St=C3=A9phane