https://bugs.kde.org/show_bug.cgi?id=491564
Adam Fontenot <adam.m.fontenot+...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |adam.m.fontenot+kde@gmail.c
| |om
--- Comment #4 from Adam Fontenot <adam.m.fontenot+...@gmail.com> ---
> This is a regression that started a few versions ago.
I seem to remember the same, though looking at the runner code I don't see how
that could have been the case. Maybe you used to have auto-complete enabled on
your KRunner history, and now that's turned off? If e.g. "restart" were
auto-completing, you would have seen that result without typing the whole thing
in. (Also if you're searching through the start menu or the search widget,
those don't have history search any more, if they ever did.)
In any case, changing the session runner code to match on `startsWith` instead
of an exact text match yields good results for me, but I'm not sure if it's
i18n friendly.
> The second issue is the prioritization of suggestions. I would expect
> it to match more in line with what fzf does. The longest exact match
> must be at the top. Later you might add additional weights based on
> the frequency of use or something but that's not important.
I think the issue with this is that KRunner groups results logically by
section, e.g. Applications, System Settings, etc, which makes sense because
they're very different sorts of results. When weird results show up it's
usually because a full search includes the descriptions and keywords of the
.desktop files, e.g. Dolphin is an unfortunate partial match with "network
shaRES". Which, yes, is really stupid, but it's hard to see how you would avoid
it and still return all relevant results. If someone *is* looking for network
shares, you probably do want to show Dolphin as an option.
Reasonable proposals for improving the search heuristics are needed I think.
E.g. maybe it makes sense to do some kind of word splitting on hidden values
like the contents of desktop files, and only match the beginnings of words. So
for example in this case Dolphin would only be shown if you typed e.g.
"netw..." or "sha...". But even this is frequently going to be unsatisfactory,
e.g. searching "abo" on this system (which I do multiple times a week, to get
to "About this System") shows "ICC Profile Info" as an application suggestion.
This program has a desktop file that contains the comment "Shows information
about an ICC profile". So realistically to make this robust you have to get
into word scoring - what's a *significant* search term? Network? Probably
significant. About? Definitely not significant, only show direct text matches,
nothing hidden.
And none of this solves the problem of ordering, and I don't have a good
solution there. Sure it makes sense for the longest exact match to be at the
top, but you have to account for priorities of multiple logical sections. If
you've typed in three letters and there are good partial matches from 5
sections, but Applications has 10 partial matches and one exact match, do you
show *all* the applications above the other sections, even though most of them
are crappy matches based on .desktop files?
There's an ongoing discussion about this at
https://invent.kde.org/frameworks/krunner/-/issues/2 where it might make sense
to plug any good ideas.
--
You are receiving this mail because:
You are watching all bug changes.
