Milou merge requestshttps://invent.kde.org/plasma/milou/-/merge_requests2024-03-11T11:02:25Zhttps://invent.kde.org/plasma/milou/-/merge_requests/79resultsmodel: Read plasma settings for KRunner favorites2024-03-11T11:02:25ZAlexander Lohnauresultsmodel: Read plasma settings for KRunner favoritesThis ensures all users of milout have the settings respected.
BUG: 480750This ensures all users of milout have the settings respected.
BUG: 4807506Alexander LohnauAlexander Lohnauhttps://invent.kde.org/plasma/milou/-/merge_requests/52Do not run match automatically when query string changed2023-03-02T19:32:32ZAlexander LohnauDo not run match automatically when query string changedBUG: 459859BUG: 4598595.27Alexander LohnauAlexander Lohnauhttps://invent.kde.org/plasma/milou/-/merge_requests/42ResultDelegate: Fix action buttons fully expanding on height2022-06-12T09:41:26ZIsmael AsensioResultDelegate: Fix action buttons fully expanding on heightThis is a problem for multiline results where the result height
can be indefinitely long.
This will change also the size of actions for single-line items. An exception could be made but at the cost of complicating the code if only a bit...This is a problem for multiline results where the result height
can be indefinitely long.
This will change also the size of actions for single-line items. An exception could be made but at the cost of complicating the code if only a bit. The icon size is the same in all the cases (small-medium: 22px), just the click area of the button changes. I'm also writing this in case someone considers it's worth to keep that case like it was before.
| BEFORE | AFTER |
|---|---|
|![multline_fullheight](/uploads/5a3b230a234bad5feac8d44b2002f367/multline_fullheight.png)|![krunner_multiline](/uploads/687d975383bca2e29383620774e21a82/krunner_multiline.png)|
|![singleline_fullheight](/uploads/9646e2fd89d258123511f22f196baa3e/singleline_fullheight.png)|![krunner_singleline](/uploads/515eba46763404777f3813edd23771b7/krunner_singleline.png)|5.25Ismael AsensioIsmael Asensiohttps://invent.kde.org/plasma/milou/-/merge_requests/41ResultDelegate: Fix height binding loop on multiline2022-05-29T10:33:59ZIsmael AsensioResultDelegate: Fix height binding loop on multilineThis binding loop was making krunner freeze when the
text expanded more than 3 lines
We shouldn't be setting the `height` on an item based on their
childrens height. Luckily, the Layout automatically calculates
this for us
BUG: 454507
...This binding loop was making krunner freeze when the
text expanded more than 3 lines
We shouldn't be setting the `height` on an item based on their
childrens height. Luckily, the Layout automatically calculates
this for us
BUG: 454507
FIXED-IN: 5.24.6
I'm not sure whether to cherry-pick this also to 5.24LTS besides 5.25?
While the bug is difficult to trigger (there are not many multiline runners still), it's quite cumbersome and makes krunner unusable in those situations, so I'd say it qualifies.5.24Ismael AsensioIsmael Asensiohttps://invent.kde.org/plasma/milou/-/merge_requests/37Avoid sorting old results based on new query input string2022-02-08T16:54:38ZEduardo CruzAvoid sorting old results based on new query input string`SortProxyModel` reorders the results provided by krunner. It uses the query input string to judge the associated results and sort them. It works great, however we have a little bug that causes a nonsensical list to be shown for the a fe...`SortProxyModel` reorders the results provided by krunner. It uses the query input string to judge the associated results and sort them. It works great, however we have a little bug that causes a nonsensical list to be shown for the a few milliseconds right after we input a new query string.
At the time `setQueryString()` is called, we still haven't received any matches result list from krunner for this new query. Milou still has the previous query's results, which are completely dissociated from the new query input.
So at this point it was doing its logic using the old results list from the previous input string, but evaluating them against the newly provided input string, which resulted in bogus behavior.
This example might make it more clear:
1 - We type string "fire" and wait for the query to finish and the final results are displayed. We get this result set:
![Screenshot_20211227_055336](/uploads/3a2711a4f873dd619ab7f0d34bc93135/Screenshot_20211227_055336.png)
2- We type one more letter, "f", so now we have "firef" as input. `SortProxyModel::setQueryString()` would set "firef" as its new `m_words` and it would call its own `invalidate()`, however at this moment the results list for "firef" haven't been provided by krunner yet: Milou still has the results list for "fire", our previous query.
So `SortProxyModel` is processing the results from "fire" using the string "firef" as criteria to judge its sorting, and this results in a quick exhibition of this bogus list to the user.
This is only shown for 250ms. It took some tries to take a screenshot of it, but here it is:
![Screenshot_20211227_055504](/uploads/de49b9e0ea584f9f90867cff9b1ca704/Screenshot_20211227_055504.png)
As we can see, we have some bogus results like "Command line: run fire" and "System Settings: Firewall" that have no business being there for the input string "firef". They are there because they are still the results from the old "fire" query. Also the ordering is different from the first list since the proxy judged the relevancy in a different manner because it's evaluating that list against the string "firef" and not "fire".
3 - 250ms later, krunner will have provided its results for "firef", and `SortProxyModel` gets in action again, now sanely sorting the "firef" result against its associated "firef" input string, and we get this final correct list:
![Screenshot_20211227_055527](/uploads/af0dce0e73aa62225e2bdc89eabb56ed/Screenshot_20211227_055527.png)
So I fixed it by not calling `SortProxyModel::setQueryString()` anymore when we have a query string change. Now we call it whenever we have a matches result set change. So the `SortProxyModel` will maintain the old query string until we receive the first result set for the new query string. That method's inner logic will detect whenever a true query string change happened and will properly call `invalidate()` when necessary.
With this patch applied, the bogus list in step 2 above will never be generated and it won't be shown to the user.
CCBUG: 4276725.24https://invent.kde.org/plasma/milou/-/merge_requests/30Fix error about "reversed" not being defined2021-06-15T14:01:40ZNate GrahamFix error about "reversed" not being definedInstead of assuming that the property is visible via the object
hierarchy, it's best to explicitly pass it around as a property to
ensure that it will always be available when queried for.
This is an alternative to https://invent.kde.or...Instead of assuming that the property is visible via the object
hierarchy, it's best to explicitly pass it around as a property to
ensure that it will always be available when queried for.
This is an alternative to https://invent.kde.org/plasma/milou/-/merge_requests/13
cc @alex @cholland5.22https://invent.kde.org/plasma/milou/-/merge_requests/25Set RunnerManager runnerWindow variable if it is available2021-03-23T10:12:16ZAlexander LohnauSet RunnerManager runnerWindow variable if it is availableCCBUG: 433173
Needed for compatibility logic in https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/723CCBUG: 433173
Needed for compatibility logic in https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/7235.21Alexander LohnauAlexander Lohnauhttps://invent.kde.org/plasma/milou/-/merge_requests/23Fix launching empty query2021-02-22T14:58:23ZAlexander LohnauFix launching empty queryIf the query is prefixed with a space the launched entry should not be
added to the history, in case there is nothing after the query the trimmed string would be empty.
@fvogtIf the query is prefixed with a space the launched entry should not be
added to the history, in case there is nothing after the query the trimmed string would be empty.
@fvogtAlexander LohnauAlexander Lohnau