This patch adds an ellipsis to the search labels in KPluginSelector (and the elements that call for it, e.g. KWin Scripts).
Details
Details
- Reviewers
kde-frameworks-devel ngraham - Group Reviewers
VDG Plasma - Maniphest Tasks
- T10258: Use correct search bars and use ellipsis whenever needed to follow the KDE HIG
- Commits
- R295:24ba84914a84: [kcmutils] Add ellipsis to search labels in KPluginSelector
Diff Detail
Diff Detail
- Repository
- R295 KCMUtils
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
| src/kpluginselector.cpp | ||
|---|---|---|
| 261 | why not "Search plugins..."? | |
| src/kpluginselector.cpp | ||
|---|---|---|
| 261 | i think it's because it's self-evident (and shorter) | |
| src/kpluginselector.cpp | ||
|---|---|---|
| 261 | a) explicit is better than implicit | |
| src/kpluginselector.cpp | ||
|---|---|---|
| 261 | a) not always - there's very little nuance here, and there's nothing to be gained by adding the word plugins (except for reinforcing that the word is a verb and that it's transitive), that's why we don't use "Type to"... besides, if we did make it explicit, we'd have to use "Search applications, places, actions etc." in kicker, "Search clipboard contents" in clipboard etc. b) "search" is a simpler and far less restrictive idea than "search plugins" in whatever language we're talking about or in, it's a single idea that doesn't call for a direct object and doubles as a noun (検索, Suche, Busca etc.) | |
Comment Actions
I think this is fine. The search field doesn't have to specify what it's going to be searching in if it's totally obvious, as it is here. This also makes it consistent with other similar instances of list-with-search-field-on-top, as in the Effects KCM.