Created attachment 110162 [details] seearchfield The fact that the search bar disappears depending on where you are may make it hard to immediately find what you look for. Would you consider making it permanent in every screen? A video is attached of the current behavior.
It used to be, then it was weird because some screens while they can have a search field it's awkward and misleading. Would it be better if we disabled it?
*** Bug 388974 has been marked as a duplicate of this bug. ***
I'm not convinced. We removed it from Updates because filtering within updates was misleading. We could make it trigger a general search every time, but then it feels a bit weird too to change the current section.
Can't iterate without feedback there.
If you can provide the information requested in comment #1, please add it.
The search field is integral for users to find information with. My request is that it shows on all screens independent of where you are.
Personally, I'd really like a "filter within updates" feature, but I don't feel like the search field is the right place for it. I'd prefer a widget in the content view itself to emphasize that it's a filter bar for the updates view, not a global search field. If we add that, perhaps we can re-add the search field and let it be a global content search again. It is on the global sidebar, after all.
*** Bug 395162 has been marked as a duplicate of this bug. ***
But the search field does not trigger a global search each time. If you are in the `Installed` tab, it only search installed apps. And on the `Settings` tab, it searched the providers list distro-repos/flatpak-repos. Even if you clicked any sub category of application or addons it only searches that category. So the easiest step right now to preserve consistency is to provide the search bar and let it search through the available updates, when informing the user through the gray background text as in the rest of the situations.
The search field itself is now visible on all pages just like originally requested, but it can still scroll out of the view. I've submitted a Kirigami patch that fixes this: https://phabricator.kde.org/D25019
Git commit cae9d9cdbd716188030b120b14e342e0356d90f1 by Nate Graham. Committed on 31/10/2019 at 20:36. Pushed by ngraham into branch 'master'. Ensure that GlobalDrawer topContent always stays on top Summary: Right now, if you define `topContent` for your GlobalDrawer, it's added to the scrollview so it can actually scroll out of sight, making it not always on top. This patch moves the `topContent` above the scrollview so it always stays on top. Test Plan: Discover's GlobalDrawer toolbar no longer strangely scrolls out of view: {F7680325} No regressions in Discover when the view is not scrollable No regressions that I could detect in Kirigami Gallery, though this probably needs lots more testing to ensure that nothing has exploded FIXED-IN: 5.64 Reviewers: #kirigami, mart, apol, ahiemstra Reviewed By: ahiemstra Subscribers: plasma-devel Tags: #kirigami Differential Revision: https://phabricator.kde.org/D25019 M +196 -195 src/controls/GlobalDrawer.qml https://commits.kde.org/kirigami/cae9d9cdbd716188030b120b14e342e0356d90f1
Re-opening because the feature got reverted because it broke other apps. There are new patches available to do it right (thanks Marco): https://phabricator.kde.org/D25425 and https://phabricator.kde.org/D25426. Those are targeting Plasma 5.18.
Git commit f365fd5e36d937ff5defa41774e41131c362ec98 by Marco Martin. Committed on 26/11/2019 at 15:26. Pushed by mart into branch 'master'. use the new GlobalDrawer header property Summary: Depends on D25425 FIXED-IN: 5.18 Test Plan: {F7774329} Reviewers: #discover_software_store, ngraham, apol Reviewed By: #discover_software_store, ngraham, apol Subscribers: apol, ngraham, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D25426 M +3 -6 discover/qml/DiscoverDrawer.qml https://commits.kde.org/discover/f365fd5e36d937ff5defa41774e41131c362ec98