- Use ellipsis and placeholder
- Extend search field
Screnshots:
Details
Details
- Reviewers
asemke - Group Reviewers
Cantor VDG - Maniphest Tasks
- T10258: Use correct search bars and use ellipsis whenever needed to follow the KDE HIG
- Commits
- R55:74db72222b17: Update search bar following kde HIG
Compile, run and work like before
Diff Detail
Diff Detail
- Repository
- R55 Cantor
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
Has the HIG updated and decided the search label needs to be removed? Anyone has a pointer as to why anyone would do that when there's no scarcity of horizontal space?
Comment Actions
Yes.
Anyone has a pointer as to why anyone would do that when there's no scarcity of horizontal space?
- This isn't always the case
- Placeholder text was invented so that we don't need these kinds of labels
- VDG thinks that things just look better this way
- Consistency is nice :)
Comment Actions
Can you point me to it? Because that's not what i saw in the HIG document that was linked from somewhere, the only thing i coudl find was "use ..."
Anyone has a pointer as to why anyone would do that when there's no scarcity of horizontal space?
- This isn't always the case
That's a very bad excuse, because in *ALL* the cases you've been removing t, it is not the problem.
- Placeholder text was invented so that we don't need these kinds of labels
No it was not, placeholder text is to give extra information that may be useful, not to describe what the field is about, because once you type on it the information goes away and when you have 4 line edits without labels and placeholders because you wrote stuff on them suddenly it's impossible to remember what each field did.
- VDG thinks that things just look better this way
- Consistency is nice :)
Comment Actions
No it was not, placeholder text is to give extra information that may be useful, not to describe what the field is about, because once you type on it the information goes away and when you have 4 line edits without labels and placeholders because you wrote stuff on them suddenly it's impossible to remember what each field did.
From the hig: Since the placeholder won’t be visible anymore as soon as the user types, you should only use it on standalone input elements, not in groups of input elements such as forms. So it this case we don't delete the label.
Comment Actions
Ok, that's clearly written by people that have no idea about what buddies are and how they work with keyboard navigation.
Since that webpage has no authorship information, do you know who should i contact about it so we can stop removing functionality on our applications?
Comment Actions
@aacid, Carl is doing nothing more than helping to implement T10258, so please don't shoot the messenger. :) If you're unhappy with the direction of this overall effort, let's discuss that there. That's why the Phab task exists: so we can discuss these kinds of projects themselves in one place, not scattered across a million review requests.
You may be correct that the HIG page was written by people who "have no idea about what buddies are and how they work with keyboard navigation" and I agree with you that this is an issue now that I'm aware of it. We'd appreciate your help to regain that lost feature alongside the effort to make the search fields throughout KDE software consistent by using placeholder text instead of buddy text to indicate the field's purpose. That way we can have the best of both worlds.
BTW The HIG definitely has authorship information; it's in the git history: https://cgit.kde.org/websites/hig-kde-org.git/
Comment Actions
Honestly, i disagree, he's proposing the changes, he's the one responsible for them.
If you're unhappy with the direction of this overall effort, let's discuss that there. That's why the Phab task exists: so we can discuss these kinds of projects themselves in one place, not scattered across a million review requests.
Ok, let's do that :)
You may be correct that the HIG page was written by people who "have no idea about what buddies are and how they work with keyboard navigation" and I agree with you that this is an issue now that I'm aware of it. We'd appreciate your help to regain that lost feature alongside the effort to make the search fields throughout KDE software consistent by using placeholder text instead of buddy text to indicate the field's purpose. That way we can have the best of both worlds.
I don't think you can, but let's talk in that phabricator task
BTW The HIG definitely has authorship information; it's in the git history: https://cgit.kde.org/websites/hig-kde-org.git/
My fault, i failed to navigate to https://hig.kde.org/resources/contribute.html
Comment Actions
Cantor doesn't have a problem with the horizontal space, this is correct. However, having both - the label with the text "Find:" and the placeholder text "Find..." in the QLineEdit - doesn't look really nice IMHO. To see what I mean we can have a look at the project explorer in LabPlot:
Here, bringing the placeholder text doesn't bring any additional value I think. It rather distracts human eyes. So, I'd like to clean up here, too. On the other side, using labels can bring an additional and clear structuring into the GUI sometimes. The placeholder text with some more informative text can act supporting here. E.g. in Cantor we could stay with the label with "Find:" and use for the placeholder text something like "Enter here the string you want to search for in the worksheet...". Here the additional value for the user is mentioning of the worksheet (we allow to search in the worksheet in this field and not in the help panel for example). But yes, at the end it's all about the consistency across the different applications...
Comment Actions
Agreed, repeating information in the placehodler that is already avaliable in the label doesn't seem to make much sense to me either