You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm making a music theory drilling game. It is pretty much entirely made with Control-based UI nodes, including the ItemList node in question.
Describe the problem or limitation you are having in your project
I'd like to use an ItemList for one of the drill's option/start scene (and others down the line as the app grows). In this first one I'm offering up a set of intervals in an ItemList that the user can choose to be tested on. The way I'd like it to work is that they can just click on each interval type that they would like to include (major 3rd, minor 3rd, etc) using just a single left click for each, and clicking an already selected item again to deselect, without having to hold down shift/ctrl to select/deselect more than one, which is a very unintuitive setup that I feel will lead most users to believe they can only select one interval type at a time, instead of as many as they would like.
Also the current multi option makes the logic for dealing with these selections much more complex and error prone than it needs to be, as selecting a second option without shift still sends the same signal that an item was selected, but doesn't say anything about the previous selection(s) that are now no longer selected visually, but can still be present in the array I'm juggling behind the scenes in response to the signals to keep track of the selections.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Having a third "toggle" mode option that treats each click on an item as a selection toggle without the need of a secondary key, would be highly useful for many simple UI designs. I've run up against this in the past and have had to cobble something together from scratch using a panel, vbox container, and separate buttons for each item I wanted in the list. Which is a lot more overhead then being able to just switch the selection mode in the existing ItemList node.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
The selection mode drop down in the inspector would just get a third option for "Toggle". On the GDScript side it would just be one more mode option that shows up in the auto-complete when using ItemList.select_mode(), probably in the form of a new constant: "SELECT_TOGGLE".
If this enhancement will not be used often, can it be worked around with a few lines of script?
As previously mentioned, I've had to replicate this functionality using a combination of several other nodes in other projects, so there is a work around but much more clunky and cumbersome to setup than it needs to be.
Is there a reason why this should be core and not an add-on in the asset library?
It is such a small addition that would fit seamlessly with the current core that it would seem foolish to add the overhead of adapting it as an add-on instead.
The text was updated successfully, but these errors were encountered:
Uradamus
changed the title
ItemList Toggle Mode
ItemList Toggle Select Mode
Feb 28, 2023
Describe the project you are working on
I'm making a music theory drilling game. It is pretty much entirely made with Control-based UI nodes, including the ItemList node in question.
Describe the problem or limitation you are having in your project
I'd like to use an ItemList for one of the drill's option/start scene (and others down the line as the app grows). In this first one I'm offering up a set of intervals in an ItemList that the user can choose to be tested on. The way I'd like it to work is that they can just click on each interval type that they would like to include (major 3rd, minor 3rd, etc) using just a single left click for each, and clicking an already selected item again to deselect, without having to hold down shift/ctrl to select/deselect more than one, which is a very unintuitive setup that I feel will lead most users to believe they can only select one interval type at a time, instead of as many as they would like.
Also the current multi option makes the logic for dealing with these selections much more complex and error prone than it needs to be, as selecting a second option without shift still sends the same signal that an item was selected, but doesn't say anything about the previous selection(s) that are now no longer selected visually, but can still be present in the array I'm juggling behind the scenes in response to the signals to keep track of the selections.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Having a third "toggle" mode option that treats each click on an item as a selection toggle without the need of a secondary key, would be highly useful for many simple UI designs. I've run up against this in the past and have had to cobble something together from scratch using a panel, vbox container, and separate buttons for each item I wanted in the list. Which is a lot more overhead then being able to just switch the selection mode in the existing ItemList node.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
The selection mode drop down in the inspector would just get a third option for "Toggle". On the GDScript side it would just be one more mode option that shows up in the auto-complete when using ItemList.select_mode(), probably in the form of a new constant: "SELECT_TOGGLE".
If this enhancement will not be used often, can it be worked around with a few lines of script?
As previously mentioned, I've had to replicate this functionality using a combination of several other nodes in other projects, so there is a work around but much more clunky and cumbersome to setup than it needs to be.
Is there a reason why this should be core and not an add-on in the asset library?
It is such a small addition that would fit seamlessly with the current core that it would seem foolish to add the overhead of adapting it as an add-on instead.
The text was updated successfully, but these errors were encountered: