| Summary: | please add possibility to sort results returned by krunner by type | ||
|---|---|---|---|
| Product: | [Plasma] krunner | Reporter: | Gandalf Lechner <gandalflechner> |
| Component: | general | Assignee: | Alexander Lohnau <alexander.lohnau> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | aeon.descriptor, alexander.lohnau, asrifox, bhush94, dashonwwIII, doglanter, gerion.entrup, giahungnguyen999, joao.vidal.silva, kde, kde, kdebugs.81do7, lakesarchive, leodream2008, linarphy, lueck, Martin, max.schettler, me, mkyral, mrboese, natalie_clarius, nate, oded, pascal, peter, pfyu817, philipp.reichmuth, qydwhotmail, renan.t.inacio, rwbarat, sequalsoft, stephan.leineweber, tagwerk19, uetsah, xojoyac741, yerimyah1 |
| Priority: | VHI | ||
| Version: | 5.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/frameworks/krunner/-/commit/666e0ec3c138da844d7129238ef8fe1ac9945863 | Version Fixed In: | 6.0 |
| Attachments: | attachment-3816389-0.html | ||
|
Description
Gandalf Lechner
2014-10-24 08:03:47 UTC
Yes, that's very annoying! For example: If I want to start ksnapshot (no PrintScr-hotkey), I must type 'ksnapshot'. If I only type 'ksnap', files with that substring in name (or content) are top-priority. If I type 'ksnapshot', then it recognizes the program. I've improved the automatic sorting to a large extent for Plasma 5.2, and it should remember your selections better. But there is still scope for improvement. Plus an explicit configuration might just be a good idea. *** Bug 209519 has been marked as a duplicate of this bug. *** *** Bug 359765 has been marked as a duplicate of this bug. *** If there were the ability to sort the plugins list (instead of being alphabetically sorted) then that should do it. I don't remember what launcher that I've used before did this, but it was a nice simple way to sort plugin priority. *** This bug has been confirmed by popular vote. *** I wished myself this feature for quite some time too, but disabling some runners worked for me so far. Also for context: https://phabricator.kde.org/R112:c2ea48d50fdaf9fa6260530e1a2eec35fb23184c And I currently have no idea on how to design/implement this. Currently the sorting priority is set in the KRunner plugins. IMO adding a sort functionality to the plugin list feels also out of place. If anyone has ideas feel free to comment. Maybe adding this as just a config key in the ~/.config/krunnerrc file? Then the implementation would be pretty easy. Similar to the font size trick mentioned in BUG 422567. @ngraham What do you think? Is this a feature worth implementing for "KRunner powerusers" or too a niche usecase? Definitely worth implementing IMO. I've wanted this for years. For comparison, macOS's equivalent feature (Spotlight) has custom sort ordering as its *only* user-facing configurable option, so I think it's definitely not a niche, power-user-only thing. *** Bug 359627 has been marked as a duplicate of this bug. *** *** Bug 340491 has been marked as a duplicate of this bug. *** *** Bug 269613 has been marked as a duplicate of this bug. *** *** Bug 428541 has been marked as a duplicate of this bug. *** *** Bug 431291 has been marked as a duplicate of this bug. *** I use krunner a lot for simple calculations and then pressing [enter] to copy the result, but when using decimals (dot) and division (slash) it prioritize the Location plugin. So for an input like "123.4/5", the first choice is "https://123.0.0.4/5", which is a very inconvenient choice to press [enter] by reflex. The only work around I found was disabling the Location plugin. krunner 5.22.5 (Ubuntu 21.04) (In reply to Renan Inácio from comment #16) >The only work around I found was disabling the > Location plugin. You could also type =123.4/5 to make sure it is not interpreted as a URL. I guess this is a documentation issue too, I made https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1102 which will hopefully make this more discoverable As well as being able to prioritize Krunner results by plugin, I'd also like to have different plugin sets and plugin orders based upon whether Krunner was invoked directly (Alt-F2) or from within Kickoff. I realize this is a big ask. And given that it adds possible complication and confusion for the user, the ability to split the Krunner configuration should probably be optional. (In reply to Alexander Lohnau from comment #17) > You could also type =123.4/5 to make sure it is not interpreted as a URL. The same problem occurs for other kinds of queries too; e.g. typing 'config.md' always shows the (non-existent) location https://config.md as the first suggestion and the actual file `config.md` second, and this has no workaround as far as I know. As for how to implement this without having to completely rewrite the KRunner logic considering that currently each plugin decides itself how important its results are: Would a possibility be to multiply the relevance values communicated by the plugins with a per-plugin relevance value configured by the user? Say files and system settings both have an applicable match but system settings ranks its results lower, and the user set KCMs to have the highest priority and files lower, then the KCM result would be taken over with its relevance unchanged, but the file result ranked down to 0.9 or so of its original relevance as the plugin ranks second in the global user configuration, and could thereby be outscored by the other category. Or something more sophisticated, but along those lines as a start? (In reply to Natalie Clarius from comment #20) > Would a possibility be to multiply the relevance > values communicated by the plugins with a per-plugin relevance value > configured by the user? This would be a step in the right direction. It would give the user some control over ranking. Is it not possible to totally override the plugin's value with one supplied by the user? (In reply to GreggB from comment #21) > (In reply to Natalie Clarius from comment #20) > > Would a possibility be to multiply the relevance > > values communicated by the plugins with a per-plugin relevance value > > configured by the user? > > This would be a step in the right direction. It would give the user some > control over ranking. Is it not possible to totally override the plugin's > value with one supplied by the user? No, because that would destroy the relevance ranking of the results within a plugin. The plugins give KRunner one absolute relevance value per search result; there is no distinction between the relevance of a plugin and the relevance of a match for that plugin. >Would a possibility be to multiply the relevance values communicated by the plugins with a per-plugin relevance value configured by the user?
Sth. like this is definitely possible. In the KRunner model we in fact differ from the relevance in certain scenarios (like the one match contains the query text and the other does not). Though this feels like a hack to work around the baloo runner being more relevant than it should be IMHO.
With parts of the KRunner UI being ported to QML, I am planning to work on this during the weekend or during the next week.
Looking forward! How would the UI for such a configurable sorting work? The most flexible would be to let the user assign arbitrary numbers as weights in the plugin list, but this is perhaps confusing? So a simple drag-and-drop ordering with the relevance decreasing in steps of 5% or so? >So a simple drag-and-drop ordering with the relevance decreasing in steps of 5% or so? Yeah, having the relevance in such percentual steps is what I had in mind. Thinking about this a bit more, there are some things that need doing first: - Port the Plasmasearch KCM to QML, because otherwise we need to redo the UI the port happens - Fix the milou workaround I mentioned - Ensure that the relevance stays in it's boundaries (only checked in one of two possible codepaths) - Ensure that the logic to increase the relevance does not interfere too much with the sorting the user has specified. https://phabricator.kde.org/T13989 touches this topic (In reply to Alexander Lohnau from comment #25) > >So a simple drag-and-drop ordering with the relevance decreasing in steps of 5% or so? While dragging the plugins around would be the ideal solution, I don't think that it is appropriate for this change. Given the underlying mechanism, I think it poses a number of problems. Firstly, re-ordering the plugins creates the expectation that the results will be similarly re-ordered. The fact that it will not, creates its own confusion for the user. Secondly, it denies the user the ability to adjust the weightings according to their needs. e.g. 100% to plugin A, 10% to plugin B and 50% to the rest. It is problematic for me because it hides from the user what they are really doing. I think a 1-10 weighting on each plugin with the default set to 5 (or 10?) would be better. A tooltip could give a brief explanation of what the field adjusts. I will makeq a mockup before implementing the UI where I will consult the VDG and add it as an attachment to this bug report. I just read the config.md example. Maybe it would also be a good idea to be able to delete (or downvote) specific search results. So, hovering above a search results makes a trashcan appear in the right corner and clicking on it just throw away this specific search result. >above a search results makes a trashcan appear in the right corner and clicking on it just throw away this specific search result.
If you mean that only for the recent documents runner I agree. Could you please file a separate feature request for it?
>- Ensure that the relevance stays in it's boundaries (only checked in one of two possible codepaths)
We actually have in QueryMatch::setRelevance code that handles this.
the milou and KCM parts are currently in review.
(In reply to Alexander Lohnau from comment #29) > >above a search results makes a trashcan appear in the right corner and clicking on it just throw away this specific search result. > > If you mean that only for the recent documents runner I agree. Why only for the recent documents runner and not KRunner globally? *** Bug 454633 has been marked as a duplicate of this bug. *** >For comparison, macOS's equivalent feature (Spotlight)
Based purely on screenshots we have fixed user-set defaults for runner ordering, then the match relevance only acts within that.
That's doable as there's only one source of truth for everything. I would really strongly advise against going down a path of having the user adjust a weighting factor within Match::setRelevance. It'll overcomplicate everything in a way that makes life harder for us and users.
(In reply to David Edmundson from comment #33) > That's doable as there's only one source of truth for everything. I would > really strongly advise against going down a path of having the user adjust a > weighting factor within Match::setRelevance. It'll overcomplicate everything > in a way that makes life harder for us and users. I would agree. Letting the user adjust group ordering but having KRunner determine ordering within groups makes sense to me. >I would agree. Letting the user adjust group ordering but having KRunner determine ordering within groups makes sense to me.
Yes that is the plan. Though I would allow configuring it on a per-runner basis. A runner might have multiple categories (for example the baloo runner has Text, Documents and Archive), but having configurability for that is technically more difficult and IMHO overkill :)
*** Bug 357985 has been marked as a duplicate of this bug. *** (In reply to Natalie Clarius from comment #19) > The same problem occurs for other kinds of queries too; e.g. typing > 'config.md' always shows the (non-existent) location https://config.md as > the first suggestion and the actual file `config.md` second, and this has no > workaround as far as I know. This is now being addressed in https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2177 Great. Thank you very much, Natalie! The more I'm working with runner code the more I think there is potential to make things better besides (instead of or in addition to) introducing yet another source of truth to ranking. Apart from my MRs to make the assignment of match types more balaned between runners, here is a new suggestion: KRunner already manipulates the relevance value, boosting frequently launched results. Move that logic into Milou, where all the rest of the sorting happens anyway, so that then instead of the relevance value (which is only used as a secondary sorting parameter and can never beat a higher match type) it can be made to affect the global ranking. And do something similar for categories, i.e. with each result launch keep a record of its category and use it to boost the rank of the category in the final sorting similar to the multiplier proposed for manual sorting, so that Milou will eventually learn user's preferences on its own. How feasible do you think this is, Alex? Git commit 1c8d9ee9a2691aebf79cbf261a66b272ebf95241 by Nate Graham, on behalf of Natalie Clarius. Committed on 31/10/2022 at 15:51. Pushed by ngraham into branch 'master'. runners/locations: decrease match type when not a known existing file M +1 -1 runners/locations/locationrunner.cpp https://invent.kde.org/plasma/plasma-workspace/commit/1c8d9ee9a2691aebf79cbf261a66b272ebf95241 Git commit 80d9f1c8e5e816c7f2ff5464379a94d177652191 by Nate Graham, on behalf of Natalie Clarius. Committed on 31/10/2022 at 16:19. Pushed by ngraham into branch 'Plasma/5.26'. runners/locations: decrease match type when not a known existing file (cherry picked from commit 1c8d9ee9a2691aebf79cbf261a66b272ebf95241) M +1 -1 runners/locations/locationrunner.cpp https://invent.kde.org/plasma/plasma-workspace/commit/80d9f1c8e5e816c7f2ff5464379a94d177652191 Thank you, Natalie and Nate. All the hard work that goes into making the krunner and thus the returned results better help of course. But that doesn't change the fact that having the option to say "I don't give a hoot what krunner thinks I want or what I have clicked in the the past - I want applications to be returned first followed by local files no matter what" would be incredibly helpful. (In reply to Peter Hoeg from comment #43) > "I want applications to be returned first followed by local files no matter what" > would be incredibly helpful. Seconded. I often enough ended up with Dolphin opening with a certain directory or kwrite opening some text file instead of the application I wanted to open, cause KRunner puts recently opened files before applications in search results. At least most of the time. For me this is the most annoying behavior of KRunner at the moment. (In reply to Martin Steigerwald from comment #44) > (In reply to Peter Hoeg from comment #43) > I often enough ended up with Dolphin opening with a certain > directory or kwrite opening some text file instead of the application I > wanted to open, cause KRunner puts recently opened files before applications > in search results. Which queries and search results exactly does this happen with? What do you type and what is the top result? Exact application matches should always be ranked highest. (In reply to Natalie Clarius from comment #45) > Which queries and search results exactly does this happen with? What do you > type and what is the top result? Exact application matches should always be > ranked highest. Well for privacy reasons I do not like to disclose any exact queries and search results. What do you mean by exact application matches? Typing the whole application name? Well that would not be what I am interested in. One of my main uses of KRunner is starting applications. And it goes like this: Alt-Space, f => Firefox, Enter. This works with many applications but it does not work with others. For Telegram for example I have two local directories first in search results, one of them being "~/Downloads/Telegram Desktop" even though I rarely access that folder. I did access that folder recently, so it is in recent files. However, I do start Telegram several times a day, cause I do not leave it running all the time. So even when it goes by number of queries to determine search order it is wrong. I even had it not working with Firefox at one time. I really like to have applications first under all circumstances. Even when I only type part of the application name. Cause that is what I do most of the time. Of course I also search for files, but usually those are not named like applications. So KRunner could easily discern. When I start searching for an application name, in 99% of the cases I like to start the application and not access a folder with the application name in its name. So the order that works best for me is: First applications. And then at some point recently used files. Never ever the other way around. This is with Plasma Workspace 4:5.26.4.1-1 on KF5 5.100.0-1 on Devuan Ceres. > best for me is: First applications. And then at some point
> recently used files. Never ever the other way around.
This is exactly my experience/wish as well.
And even if I have a partial match on an application, I would rather have that as the first option compared to an exact match for anything else.
Going further down the line, I would also like a partial match for a file before an exact match for a browser tab as an example.
krunner has become smarter over the years, but I quite frankly don’t really need it to be smart. Just follow an order/priority I specify. And other people are of course very likely to have different priorities.
Thanks for the info. Yes, by "exact match" I mean typing the full name. Quickly opening an application by typing part of its name and always wanting certain categories first seems like a reasonable use case. I still think that extending the logic of boosting the relevance of frequently launched to pushing the ranking of a category as a whole would solve this use case while keeping it simple both UX and code wise; but I'd like to her Alex' opinion on this first. > I still think that extending the logic of boosting the relevance of frequently
> launched to pushing the ranking of a category as a whole would solve this use case
There are other use cases that it will not address so maybe we should try to map out the use cases first?
1. Because I use krunner as the main application launcher, I want applications to show first no matter what,
2. I rarely open a directory from krunner, but often open files, so I want a partial file match to show before an exact folder match. Frequency of use of the file doesn’t matter - it’s always files before folders.
3. I have had to disable the “Command Line” plugin because it would often match short words and thus rise to the top, but it would be convenient to still have around if I had the option to always put it at the end of the result list.
4. I rarely use browser tab switcher but it’s nice enough to have around. But it often rises to the top despite me *very* rarely actually selecting a tab this way.
Please don’t misunderstand the “I want” part - I’m not demanding anything, just outlining the use-case.
And the thing is - these are all personal preferences so no amount of smarts is really going to be able to suit people’s individual preferences and workflows when we are talking about “I *always* want this to happen first, no exceptions”.
Lastly, can I just say that krunner in general is phenomenal. We are firmly in the “nice to have” territory when it comes to this feature request.
Thanks Natalie and Peter for commenting. Peter, I agree with you. For example I often enough also open directories, so for me files first might not match my exact use case. As I understood setting your own preferences would be difficult to implement. I think I remember that the individual runners decide upon their priority themselves. So I'd also be grateful for just the applications first case working out of the box. And agreed: KRunner is awesome. It is one of the most awesome parts of Plasma desktop. I never seen a runner that works as good as this one on any other desktop environment or operating system. So yeah, thank you to all the developers on the great work on it! There is an opportunity though to even make it even awesomely awesome. :) > 2. I rarely open a directory from krunner, but often open files, so I want a partial file match to show before an exact folder match. Frequency of use of the file doesn’t matter - it’s always files before folders.
This won't be achievable with a custom ordering of runner plugins as files and folders are provided by the same plugin. It would be possible if one were to use adaptive relevance based on category names rather than plugins.
All your other points seem reasonable to have and possible to achieve as well.
I really like krunner! But I sometimes don't know if the recent frequency thing works as expected, maybe someone can explain to me how it works. Example: I use geary as mail client, I installed KMail to test it and ran it once (!). From that moment on, when typing "mail" KMail always shows on top and then geary second, even though I choose geary every time for two months now. So it feels a bit frustrating that krunner won't learn that I'd like geary to be first. Maybe this is a bit unlucky because "mail" is in the word "KMail" but not in the word "Geary", and so despite the fact I use Geary in 99.8% of cases krunner thinks KMail is a better match because it's in the title of the application. I use krunner as quick starter for applications mainly, so I'd appreciate some refining on these cases, so that applications that are used very often (several times per session) are always the first entry. Best regards Stephan Thanks for the comment Stephan. Your issue seems legitimate, but can be fixed without the need to implement user-customizable category ordering--and in fact, implementing it would not help, since the results in question are both *within* a category. Can y please file a new bug report for that? Thanks! If I understand Stephan's comment correctly, he suspects gbat the existing launch count boost for results within a category is not doing a good job, and questions how useful a similar mechanisms for categories would be. Am I understanding you correctly? In any event, I'm not sure if this is what causes the problem so it should be investigated in a separate thread, and if it is, then of course it should be improved. KRunner is great - the best launcher I've used so far - but I would be very happy if this was customizable to some extent. For example, I'd like to be able to have applications ranked higher than recently opened files. Here are two use cases for that: - I open a downloaded AppImage to test it, then make a desktop file in ~/.local/share/applications for it. However since the AppImage counts as a recently opened file, the AppImage file is always listed above the desktop entry. - Sometimes when typing an app name in KRunner and hitting Enter quickly, the list of search results gets updated with some files from Baloo before I hit Enter. So Enter then opens a file instead of the app, and henceforth the file will now be ranked higher than the app because it now is a recently opened file. This has happened to me with Telegram: in between me typing "telegram" and hitting Enter, Baloo served up the Telegram icon file "telegram.svg", and since it now counts as a recently opened file, the icon file always gets ranked higher than the app and I need to press a few arrow keys to get the app. So an UI that would consistently have me rank certain results above or below certain other results would help me a lot. With the default sorting orders, I had to stop indexing hidden files and folder because krunner presented me the configuration directory (under ~/.config) before the actual application, making it complicated to get the application A possibly relevant merge request was started @ https://invent.kde.org/multimedia/audiocd-kio/-/merge_requests/7 Git commit 2c7e60447c62e955b3975012b4427ccd5aa71ee1 by Alexander Lohnau. Committed on 13/02/2023 at 07:47. Pushed by alex into branch 'master'. Add BugReportUrl to json metadata M +1 -0 src/konfigurator/kwalletconfig.json https://invent.kde.org/utilities/kwalletmanager/commit/2c7e60447c62e955b3975012b4427ccd5aa71ee1 A possibly relevant merge request was started @ https://invent.kde.org/graphics/kamera/-/merge_requests/6 Sorry for the noise, I copied the wrong bugnumber by accident :/ I'm not sure what the best way is to move this forward is - and if we possibly should be splitting this into multiple tickets since there are multiple issues (although obviously related). 1. the ordering of groups a. statically, or b. with weights 2. the ordering of items within groups a. statically, or b. with weights 3. issues with the "smarts" where the automatic ordering doesn't seem to actually take use frequency into consideration What's the best way forward from here? (In reply to Peter Hoeg from comment #61) > I'm not sure what the best way is to move this forward is - and if we > possibly should be splitting this into multiple tickets since there are > multiple issues (although obviously related). > > 1. the ordering of groups > a. statically, or > b. with weights > 2. the ordering of items within groups > a. statically, or > b. with weights > 3. issues with the "smarts" where the automatic ordering doesn't seem to > actually take use frequency into consideration > > What's the best way forward from here? Sorry guys, I've forgotten to tell here. Issue 3 doesn't exist anymore since, at least for me. Since an update the ordering of the mail client is as expected. Thanks for refining the order of the results! Don't know about issue 1 and 2, since those were asked by other persons... Created attachment 158198 [details] attachment-3816389-0.html This specific issue is about #1. The other issues were brought up here due to their close similarity, but this is really about issue 1. Sorting by krunner type is most simply done by a reorderable list, as it was in KDE a while back. If more complexity is desired, a list with weights on the right hand side. But the first is all that was originally asked for. This issue stalled on addendums. On Tue, Apr 18, 2023, 3:46 PM <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=340283 > > --- Comment #62 from stephan.leineweber@t-online.de --- > (In reply to Peter Hoeg from comment #61) > > I'm not sure what the best way is to move this forward is - and if we > > possibly should be splitting this into multiple tickets since there are > > multiple issues (although obviously related). > > > > 1. the ordering of groups > > a. statically, or > > b. with weights > > 2. the ordering of items within groups > > a. statically, or > > b. with weights > > 3. issues with the "smarts" where the automatic ordering doesn't seem to > > actually take use frequency into consideration > > > > What's the best way forward from here? > > Sorry guys, I've forgotten to tell here. Issue 3 doesn't exist anymore > since, > at least for me. Since an update the ordering of the mail client is as > expected. Thanks for refining the order of the results! Don't know about > issue > 1 and 2, since those were asked by other persons... > > -- > You are receiving this mail because: > You are on the CC list for the bug. A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kcmutils/-/merge_requests/155 A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1610 The visuals for it are done. Now it needs to be implemented in the KRunner API. I will do some less invasive refactorings first to avoid having multiple incompatible changes at the same time in review. https://invent.kde.org/frameworks/krunner/-/merge_requests/150 https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1610 Those are the two changes needed in addition to the plasma-desktop patch. Git commit 666e0ec3c138da844d7129238ef8fe1ac9945863 by Alexander Lohnau. Committed on 28/08/2023 at 06:38. Pushed by alex into branch 'master'. Implement sorting of custom runners This patch exposes methods to set favorite plugins. They are respected in the internal sorting by keeping them in a fixed order. Prerequisite for: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1610 https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3201 M +22 -1 src/model/resultsmodel.cpp M +11 -0 src/model/resultsmodel.h M +14 -0 src/model/runnerresultsmodel.cpp M +1 -0 src/model/runnerresultsmodel_p.h https://invent.kde.org/frameworks/krunner/-/commit/666e0ec3c138da844d7129238ef8fe1ac9945863 Thank you very much, Alexander! I greatly appreciate it. Git commit 9cb32652ea3b7f44bfc06ce0a8a72833468bb89a by Alexander Lohnau. Committed on 01/09/2023 at 20:34. Pushed by alex into branch 'master'. KPluginModel: Allow consumers to implement custom drag/drop sorting This is required for the plasmasearch KCM. Because we want to not leak too many things in the framework, we just allow `leading` to be overwritten by any component and hide the checkbox if needed. M +49 -0 src/core/kpluginmodel.cpp M +15 -0 src/core/kpluginmodel.h M +4 -1 src/core/kpluginproxymodel.cpp M +1 -0 src/core/kpluginproxymodel.h M +2 -2 src/qml/components/PluginDelegate.qml https://invent.kde.org/frameworks/kcmutils/-/commit/9cb32652ea3b7f44bfc06ce0a8a72833468bb89a Git commit 9e09e4ee86bf32450a5b0a51568cd2027e5e7722 by Alexander Lohnau. Committed on 01/09/2023 at 20:29. Pushed by alex into branch 'master'. Implement sorting of favorite runners Counterpart of https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1610 To avoid the KRunner::ResultsModel having to know about the implementation details how we set this config, a property is assigned to the model. This also helps with keeping default values (like the krunner_services favorite) in sync with the plasma-desktop bits. M +6 -5 krunner/qml/RunCommand.qml M +5 -1 krunner/view.cpp M +10 -4 krunner/view.h https://invent.kde.org/plasma/plasma-workspace/-/commit/9e09e4ee86bf32450a5b0a51568cd2027e5e7722 Git commit 51422eebf10830d8b9e22487cbfd8d73dd5e5992 by Nate Graham, on behalf of Alexander Lohnau. Committed on 02/09/2023 at 07:08. Pushed by ngraham into branch 'master'. Implement sorting of favorite runners This way users can configure the order of their favorite plugins. The order for those plugins is fixed and all custom plugins will be shown afterward. The KRunner framework implementation of this still needs to be done, but that should be done in combination with some other sorting refactorings. M +0 -1 kcms/runners/plasmasearch/CMakeLists.txt M +53 -9 kcms/runners/plasmasearch/kcm.cpp M +25 -1 kcms/runners/plasmasearch/kcm.h M +30 -2 kcms/runners/plasmasearch/ui/main.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/51422eebf10830d8b9e22487cbfd8d73dd5e5992 *** Bug 473364 has been marked as a duplicate of this bug. *** >Thank you very much, Alexander!
Happy to do so! Just some API refactorings and then the sorting mechanism is ready for KF6 ;)
|