| Summary: | Order search results the same way as in KRunner | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Nate Graham <nate> |
| Component: | Application Launcher (Kickoff) | Assignee: | Alexander Lohnau <alexander.lohnau> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | alexander.lohnau, amanita+KDEBUGS, bugseforuns, colinetnathan98, dagobertram, liubomirwm, n8thefusion, plasma-bugs, postix, pqwoerituytrueiwoq, putr4.s, slavi |
| Priority: | HI | Keywords: | usability |
| Version: | master | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=357985 | ||
| Latest Commit: | https://invent.kde.org/plasma/plasma-workspace/commit/7a6bf2d15b791da8d765b40a41d3cfa83c821cd6 | Version Fixed In: | 6.0 |
|
Description
Nate Graham
2021-01-06 03:01:25 UTC
It is a KF6 goal to provide a standardized model. But TBH the sorting is really weird and there are also hacks here and there implemented. Like https://phabricator.kde.org/D22888. *** Bug 438860 has been marked as a duplicate of this bug. *** 1. May I ask how Kickoff differs from KRunner except of showing more than just the search bar when activated? It might be confusing for newcomers why there are two tools doing pretty much the same stuff. 2. Do we really need both when we say "simple by default, powerful when needed"? (In reply to dagobertram from comment #3) > 2. Do we really need both when we say "simple by default, powerful when > needed"? ... at least in the standard configuration. Indeed, at this point they do the same things. However KRunner is an invisible UI that is totally out of the way and unobtrusive, so I'm not sure how important it is to remove from the default configuration. Does this bug also include grouping results like: * Browser tabs * Browser history * Image * Document * Software centre * etc... Yes, they are already grouped. However the order of groups is difference in Kickoff vs KRunner, which is why this bug report is open. Well i kinda imagine it like no scrolling once menu opens - all initially shown content's height taken together takes at most the height of the menu itself. Each group has group name displayed above its results with smaller font size than the results themself. The number of entries shown in this initial view is possibly calculated this way - each group shows the same number of entries like all the other groups, for example if the height allows it there are 3 entries shown for each group, but if height doesn't allow it then there are 2 entries shown for each group. Minimum number of entries per group is 1, and if menu height doesn't allow showing each group with at least one result per group, then and only then the menu can scroll with the initial results/show up. If you want to see more results from specific group then there can be some button for each group which replaces all content of the menu with all the results from this group and only from this group (scrolling is allowed of course here). Nevermind as you'll find it way too convoluted and would not implement it - take it as a plan or as a science-fiction as per your liking. *** Bug 448196 has been marked as a duplicate of this bug. *** *** Bug 446239 has been marked as a duplicate of this bug. *** *** Bug 459489 has been marked as a duplicate of this bug. *** *** Bug 460836 has been marked as a duplicate of this bug. *** I have a working version of this on Plasma (with Qt6). *** Bug 467975 has been marked as a duplicate of this bug. *** A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2802 Git commit 7a6bf2d15b791da8d765b40a41d3cfa83c821cd6 by Alexander Lohnau. Committed on 23/04/2023 at 17:24. Pushed by alex into branch 'master'. applets/kicker: Replace RunnerMatchesModel sorting with KRunner::ResultsModel We still need to provide additional features, like the context menu actions. But the sorting will be the same. Also, each KRunner::ResultsModel takes care of managing the RunnerManager internally. Meaning we can not have one shared RunnerManager and then redistribute the results to different models in case we have mergeResults=false. Instead, we have multiple ResultsModels in case mergeResults is false, but each RunnerManager loads exactly one runner. This also means that we should not delete the models after the query changed, because the plugin instantiation and initialization would cause overhead. FIXED-IN: 6.0 M +28 -68 applets/kicker/plugin/runnermatchesmodel.cpp M +8 -14 applets/kicker/plugin/runnermatchesmodel.h M +36 -183 applets/kicker/plugin/runnermodel.cpp M +2 -3 applets/kicker/plugin/runnermodel.h https://invent.kde.org/plasma/plasma-workspace/commit/7a6bf2d15b791da8d765b40a41d3cfa83c821cd6 |