r3bl-org/r3bl-open-core

[tuify] Create a function that allows multiple selections from a list of strings

Closed this issue ยท 7 comments

Context:

Currently only single selection is supported in both rt and the library in r3bl_tuify.

Implement the SelectionMode::MultiSelect. Related to:

  • r3bl-org/r3bl_tuify#1

Quick question, just to get an idea of what's required here and see if I'm going in the right direction:

  • Provide SelectionMode::MultiSelect
  • Provide a MultiSelectComponent which should be similar to the existing SingleSelectComponent.
  • Update select_from_list to make use of these components.

@johnmcl001 Thank you so much for spending time on this issue ๐ŸŽ‰ . And for confirming the direction prior to proceeding. You are 100% on the right track ๐Ÿ‘๐Ÿฝ .

To support "multiple selection mode", in addition to all the other things you pointed out, the State will be affected as well.

https://github.com/r3bl-org/r3bl_rs_utils/blob/bb620bb348fd88a9874ffadf4eda783e8c1429da/tuify/src/public_api.rs#L172

  • The State will need to "remember" what items are selected in multiple selection mode (since the user can select multiple items, and unselect them, before pressing Enter to finalize their choice(s)).
  • Also the Space key press has to be handled as well, since that is how the user will be able to toggle selecting an item that is currently focused in the UI. This will require changes to keypress.rs

With single selection it is enough to have raw_caret_row_index to remember what the user has chosen, but for multiple selections, it will probably need to be a Vec<String>.

https://github.com/r3bl-org/r3bl_rs_utils/blob/bb620bb348fd88a9874ffadf4eda783e8c1429da/tuify/src/state.rs#L28

Please let me know if you have more questions ๐Ÿ™๐Ÿฝ .

Thanks, you've just answered my next question about using space to do multi-selects ๐Ÿ‘ .
I'll get started on registering the new key press and come back to you with any more questions.

Almost finished with this now, just had 2 questions about the SingleSelectComponent.

1:

  • From what I can see, this is only used in rendering items regardless of SelectionMode.
  • If SelectionMode::Single is used then it is fine as is but if SelectionMode::Multiple is used then we want it to highlight which options the user has currently selected, as indicated by this TODO:
// TODO: use styles for selected and unselected
  • Rather than add in a new MutliSelectComponent like I said above, we could just rename SingleSelectComponent to SelectComponent and include the logic for selection styles here.
  • This means we don't have to select a different SelectComponent in public_api.rs depending on the SelectionMode.
  • From the user's point of view:
    • If the mode is SelectionMode::Single they will never see the selection style applied since the program will exit and display the user's selection immediately, i.e: current behavior is unaffected.
    • If the mode is SelectionMode::Multiple then the styles will be applied as needed.
  • Let me know what you think about having a single SelectComponent for use with both modes.

2:

  • I was going to add a basic selection style which inverts bg_color and fg_color for multi-select to address the TODO I mentioned above, if this falls outside the scope of this issue I'll hold off on doing it for now.

@johnmcl001 If you would like to chat in real time, please join this discord server: https://discord.gg/kgYck6f5

  1. Re: single SelectComponent

    • I agree w/ you 100%. Having a single SelectComponent makes a lot of sense. Let's go with this approach ๐ŸŽ‰
  2. Re: selection colors

    • For now, let's go w/ what you propose ๐ŸŽ‰

There's an open issue to add styling to this crate, so that users will be able to pass in whatever "style sheet" struct they would like, and then we don't have to hard code these colors anymore, by providing a default "style sheet".

Here's the issue for this

@johnmcl001 This isn't directly related to what you are currently working on, but I just wanted to give you heads up of this branch that I'm working on. I've found some bugs in the main branch that are fixed here

Not to worry, we can land your PR first (whenever it is ready) and then merge this branch after that.

Please see PR #132