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 have a use-case for pick where i want to display say items 1..8, but two of them, 3 and 6 are not viable options, but 'known' to the underlying system. The user shouldn't be able to select the not viable items, as that would make them expect that action is taken, whereas that is not the case, because it's not possible to do so. I want to be able to visualize that fact that these items are 'known' and not simply leave them out as the user wouldn't be able to differentiate between unknown and disabled items.
I can imagine two different ways to visually represent that.
I think option 1 is preferable, considering lists can be longer than a screen is high, making option 2 non-straight-forward to grasp):
Keep the list and its ordering as provided to the pick function, visually differentiating the disabled from the enabled options (different color, prefix, something like that).
Disabled options are skipped when navigating the list
Presenting enabled and disabled items in two separate lists.
A necessary implication is that items passed to pick() must be tuples, indicating for each item whether it is enabled or disabled.
The text was updated successfully, but these errors were encountered:
I think it makes sense to extend the option strings to a option class, with various customisation possibilities and styles. An option could be non-selectable, or purely text between option groups and etc.
I have a use-case for pick where i want to display say items 1..8, but two of them, 3 and 6 are not viable options, but 'known' to the underlying system. The user shouldn't be able to select the not viable items, as that would make them expect that action is taken, whereas that is not the case, because it's not possible to do so. I want to be able to visualize that fact that these items are 'known' and not simply leave them out as the user wouldn't be able to differentiate between unknown and disabled items.
I can imagine two different ways to visually represent that.
I think option 1 is preferable, considering lists can be longer than a screen is high, making option 2 non-straight-forward to grasp):
Keep the list and its ordering as provided to the pick function, visually differentiating the disabled from the enabled options (different color, prefix, something like that).
Disabled options are skipped when navigating the list
Presenting enabled and disabled items in two separate lists.
A necessary implication is that items passed to pick() must be tuples, indicating for each item whether it is enabled or disabled.
The text was updated successfully, but these errors were encountered: