Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow multiple values selection in dropdown menus #1456

Closed
Botan626 opened this issue Jun 30, 2021 · 12 comments
Closed

Allow multiple values selection in dropdown menus #1456

Botan626 opened this issue Jun 30, 2021 · 12 comments
Labels
✨ Enhancement Issues marked with this label indicate further enhancements to the program, such as new features. 💢 No solution yet Issues marked with this label indicate that we don't have any idea how to solve this problem yet. 👍 PR-ok Issues marked with this label are good candidates for being accepted in a pull request.

Comments

@Botan626
Copy link
Contributor

Purpose

To have a possibility to select multiple values in the dropdown menu, until it's closed with an outside mouse click.
@Botan626 Botan626 added ✨ Enhancement Issues marked with this label indicate further enhancements to the program, such as new features. 🧐 Evaluation Issues marked with this label are currently being evaluated if they're going to be considered. labels Jun 30, 2021
@Abrynos
Copy link
Member

Abrynos commented Jun 30, 2021

As I previously layed out in my merge request over here: I am not a fan of this idea.

@Botan626
Copy link
Contributor Author

Botan626 commented Jun 30, 2021 •
edited
Loading

As I previously layed out in my merge request over here: I am not a fan of this idea.

You said multiple times, that it's hard for you to implement it. You didn't give a reason, why you don't like this idea itself.

@Abrynos
Copy link
Member

Abrynos commented Jun 30, 2021

[...] get [this idea] working with InputList where the order of selection matters [...], without having two (or rather three) extremely similar types of input being displayed in two completely different ways.

Why would we display them differently? Because if we leave the dropdown open it hides the items below the dropdown menu, which is how the user can see in which order the selected values are.

Additionally I cannot see a way of keeping our current "None" option, which in my opinion is rather important. This is a classic case of one "checkmark" in a selection changing the state of another "checkmark", which is something you usually want to avoid.

There is also the problem of clicking on the "background". Currently we close the whole modal when doing that.

And the most important thing to keep in mind is simplicity. You want any GUI to be as simple as possible for the user. A plain dropdown menu is simple. A dropdown menu with checkboxes inside is not (in comparison). In that case we could just make the whole thing checkboxes in the first place and remove the dropdown and "badges" below it completely. (I am against that as well, because it makes the whole thing much bigger, clutters your screen and you'll have more scrolling to do to find the config property you are searching for 😉)

@Botan626
Copy link
Contributor Author

Why would we display them differently? Because if we leave the dropdown open it hides the items below the dropdown menu, which is how the user can see in which order the selected values are.

1st, I have no idea what you are quoting. I read this part and stopped reading. This already had answer in this comment #1450 (comment)

I just had another idea. The dropdown menu could be without checkboxes, but it could allow to multi select property values, until it's closed. Selected values could be highlighted with ui's theme color, and focused values could be highlighted with pale grey color.

Should I continue reading, or maybe you want to rethink your comment and edit it?

@Botan626
Copy link
Contributor Author

[...] get [this idea] working with InputList where the order of selection matters [...], without having two (or rather three) extremely similar types of input being displayed in two completely different ways.

Why would we display them differently? Because if we leave the dropdown open it hides the items below the dropdown menu, which is how the user can see in which order the selected values are.

Additionally I cannot see a way of keeping our current "None" option, which in my opinion is rather important. This is a classic case of one "checkmark" in a selection changing the state of another "checkmark", which is something you usually want to avoid.

There is also the problem of clicking on the "background". Currently we close the whole modal when doing that.

And the most important thing to keep in mind is simplicity. You want any GUI to be as simple as possible for the user. A plain dropdown menu is simple. A dropdown menu with checkboxes inside is not (in comparison). In that case we could just make the whole thing checkboxes in the first place and remove the dropdown and "badges" below it completely. (I am against that as well, because it makes the whole thing much bigger, clutters your screen and you'll have more scrolling to do to find the config property you are searching for 😉)

Did you mean to comment for this issue #1458 ?

@Abrynos
Copy link
Member

Abrynos commented Jun 30, 2021

The dropdown menu could be without checkboxes, but it could allow to multi select property values, until it's closed. Selected values could be highlighted with ui's theme color, and focused values could be highlighted with pale grey color.

This is still a dropdown menu with checkboxes. Making it look a bit different won't change that fact.

Did you mean to comment for this issue

no

@Botan626
Copy link
Contributor Author

Because if we leave the dropdown open it hides the items below the dropdown menu, which is how the user can see in which order the selected values are.

And why it is bad?

Additionally I cannot see a way of keeping our current "None" option, which in my opinion is rather important. This is a classic case of one "checkmark" in a selection changing the state of another "checkmark", which is something you usually want to avoid.

Why?

There is also the problem of clicking on the "background". Currently we close the whole modal when doing that.

What is the problem?

You want any GUI to be as simple as possible for the user.

It can also be convenient for users.

@MrBurrBurr MrBurrBurr added 👍 PR-ok Issues marked with this label are good candidates for being accepted in a pull request. 💢 No solution yet Issues marked with this label indicate that we don't have any idea how to solve this problem yet. and removed 🧐 Evaluation Issues marked with this label are currently being evaluated if they're going to be considered. labels Jun 30, 2021
@Abrynos
Copy link
Member

Abrynos commented Jun 30, 2021 •
edited
Loading

As I said on discord: I am not participating in this discussion any more (at least not responding to your comments).

Other than "it may be convenient" you got nothing to support this suggestion and I have laid out plenty of reasons against it. Accept it, proof me wrong or find some more reasons.

@MrBurrBurr
Copy link
Member

Small enhancement for the user, huge pain in the ass for a dev.

If someone wants so create a PR that takes care of every mentioned concern I will gladly accept it.
Until then this issue will stay closed.

@Botan626
Copy link
Contributor Author

proof me wrong

No, it's you who has to proof values of your weak reasons. Maybe it's hard to code, I don't know, all other reasons you say here are just irrelevant.

@Botan626
Copy link
Contributor Author

takes care of every mentioned concern

What every concern? DD menu already hides selected values. Why 'None' option has to go? Backgroung thing I don't get at all.

What about Wishlist label?

@MrBurrBurr
Copy link
Member

What every concern? DD menu already hides selected values. Why 'None' option has to go? Backgroung thing I don't get at all.

Abry already explained most of the concern I have about this enhancement. It's really complicated to implement in a way that is maintainable, readable and works. It might seem easy for someone that does not understand how to code. But it is still a valid suggestion, that's why I added the PR-ok label and not the Not going to happen label.

What about Wishlist label?

We do not set Whishlist label and No solution yet label at the same time. No point in doing so.

@JustArchiNET JustArchiNET locked as spam and limited conversation to collaborators Jun 30, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
✨ Enhancement Issues marked with this label indicate further enhancements to the program, such as new features. 💢 No solution yet Issues marked with this label indicate that we don't have any idea how to solve this problem yet. 👍 PR-ok Issues marked with this label are good candidates for being accepted in a pull request.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Abrynos @Botan626 @MrBurrBurr