kamik423 / cutie Goto Github PK

cutie.select is not selecting on use of the arrow keys.

e.g. on the press of the up arrow key cutie will treat that as a press of the return key and advance the program without changing selection.

I reverted to readchar 3.0.4 and the error did not persist and cutie now works as expected.

IDE: pycharm 2021.2 community edition with terminal emulation turned on.
Running python 3.9 although the issue persists on 3.7 when using the latest version of readchar.

Hi @Kamik423

Cutie v0.2.2 do not allow user to quit multiple selection function. And the KeyboardInterrupt support in all three functions are not released but in dev branch. Do you have any plans to release your dev branch?

Thanks

Very nice project! Some small remarks:

• instead of while 1 use while True for an infinite loop
• the folder __pycache__ shouldn't be on GitHub; put it in .gitignore

Update: when you create a new repo, you can select the language and GitHub offers to create a .gitignore file for you. The default .gitignore for Python is quite long and includes __pycache__.
Update 2: a requirements.txt would be nice too if someone wants to download and install it in a virtual environment.

Using select_multiple with minimal_count and hide_confirm=True leads to unresponsivness.

When trying to confirm, the user isn't prompted with a feedback and the state just doesn't change.
Keyboard interrupt via CTRL + C doesn't work either, the CLI is just unresponsive until the right amount of options are selected

Code to repoduce the issue:
cutie.select_multiple(["foo", "bar"], minimal_count=1, hide_confirm=True)

Keys entered into prompt_yes_or_no do not work if they are in the arrow key list.

This currently concerns jk, which do not pose a real issue for the English language, but if for example configuring the prompt_yes_or_no to German (Ja/Nein) this poses a critical issue.

It would be great if you could search/filter results, especially on larger multi-select lists.
Maybe similar to how simple_term_menu implements it?

When using a simple cutie.select on Windows, a CPU core will be pegged to 80~90% while waiting for input due to readchar.

I tried switching to using this method with msvcrt.getch() and it seemed to use near 2% CPU usage while waiting for character input for comparison.

(In the screenshot the CPU has hyperthreading so even though 2 are pegged it's just a single core.)

Edit: I am going to open an issue on readchar, because it's a really easy fix of a while loop gone astray. magmax/python-readchar#42

When pip3 installing cutie, the version of cutie that is installed is cutie-0.2.1

The select function in this version does not have an argument for caption indices:

def select(
        options: List[str],
        deselected_prefix: str = '\033[1m[ ]\033[0m ',
        selected_prefix: str = '\033[1m[\033[32;1mx\033[0;1m]\033[0m ',
        selected_index: int = 0) -> int:
    """Select an option from a list.

    Args:
        options (List[str]): The options to select from.
        deselected_prefix (str, optional): Prefix for deselected option ([ ]).
        selected_prefix (str, optional): Prefix for selected option ([x]).
        selected_index (int, optional): The index to be selected at first.

    Returns:
        int: The index that has been selected.
    """
    print('\n' * (len(options) - 1))
    while 1:
        print(f'\033[{len(options) + 1}A')
        for i, option in enumerate(options):
            print('\033[K{}{}'.format(
                selected_prefix if i == selected_index else deselected_prefix,
                option))
        keypress = readchar.readkey()
        if keypress == readchar.key.UP:
            selected_index = max(selected_index - 1, 0)
        elif keypress == readchar.key.DOWN:
            selected_index = min(selected_index + 1, len(options) - 1)
        else:
            break
    return selected_index

Are there plans to distribute the version of cutie that has the features as the example in the readme? I like the caption indices feature but currently do not have access to it.

As discussed in #7 it would make a lot of sense to shift cutie to a class structure to allow for overall customizability. This is a modified and updated version of the last post in there:

My reasoning for not wrapping it in a class was that the module should be very straightforward to use. I want the user to be able to call the functions directly without having to create a class instance first. I do not think that most users will really want to customize a lot. The strength of this module lies in its was of use, like prompting a yes or no question in a single straightforward line of human readable python.

My suggestion:

Option 1

• Add a class CutieConfiguration(ABC) which implements the functions but has abstract properties for keys and prefix strings etc. This is for users who want to customize every single bit without building on top of the default.
• Have a class DefaultCutieConfiguration(CutieConfiguration) wich contains the default key maps and prefixes (like [+]) for users who only want to tweak details
• Keep the current functions but strip out the implementation (which is in CutieConfiguration). When they get called they create a DefaultCutieConfiguration object and call its function. This keeps it simplest for users not seeking to customize anything.

Maybe CutieConfiguration and DefaultCutieConfiguration should be in the same class, I just think it is cleaner having those two separated.

Option 2

• It would also make sense to have a class per function, which have a run method (or so). I have a few reasons for this:
  • It would (like the CutieConfiguration from Option 1) reduce the amount of arguments being passed to a function.
  • Things like prefixes could be put into their own function, so there could be different prefixes for each line. Implementing this is unfeasible in the current structure. Example:

     1.  Foo
    [2.] Bar
     3.  Foobar
    

  • Unlike in the CutieConfiguration when just creating (for example) a custom select it would not contain configuration information for prompt_yes_or_no.
  • It would make it quite simple to use a modified version of a prompt multiple times.
  • HOWEVER there would have to be a separate way of storing key information. I can spontaneously come up with two solutions:
    • Using inner (nested) classes:

      class CutieConfiguration:
          class Keys:
              up: List[str] = [readchar.key.UP, 'k']
              ...
      
           class Select:
              def prefix(self, line: int, is_selected: bool) -> str:
                  return '[x]' if is_selected else '[ ]'
      
              def run(self) -> int:
                  ...
      
              ...

    • Or referencing a Configuration object from each Function.
  • Once again I'd leave the currently existing functions in place, but have them instantiate a preset default object to keep simple minimal cases.

I prefer option 2.

What do you think? Is there a better way or anything I am missing?

Using cutie.prompt_yes_or_no() and entering a long enough string - or just a moderately-sized string and resizing the console window just enough so it wraps - then typing or using the arrow keys to move the selector will completely break the display.

Resizing the window back so the original prompt will fit again will 'fix' the issue, though the duplicated lines will persist.

Input question string for the below was testtesttesttesttesttesttesttesttesttesttesttesttesttest.

One key should represent one action, and having the tick action bound to ENTER and SPACE is redundant, plus it is a few extra steps to confirm input.

Selecting with SPACE and confirming with ENTER is more intuitive and faster, so i think this should be the default option.

I'm testing out running the select menu on an unknown depth configuration dictionary like so:

while hasattr(workingLibrary, "keys"):
    print("Available Configurations")
    choices = list(workingLibrary.keys())
    workingLibrary = workingLibrary[choices[cutie.select(choices)]]

After the first loop, it appears as though there is an erroneous keypress (in my case a letter P) detected and waiting in the buffer. When I use the arrows to make the 2nd selection, two key presses are detected/passed and it breaks out of that selection and continues on to the 3rd. This behaviour repeats until I hit the end of the dict. I added the following code to your init.py from Rosetta Code:

def flush_input():
    try:
        import msvcrt
        while msvcrt.kbhit():
            msvcrt.getch()
    except ImportError:
        import sys, termios    #for linux/unix
        termios.tcflush(sys.stdin, termios.TCIOFLUSH)

And call that function immediately before "keypress = readchar.readkey()" and it solves the issue. I've tried to track down the source of the erroneous keypress, but haven't had any luck.

When using select_multiple with minimal_count=True, trying to confirm when too few options are selected results in an error being displayed.

However, when using maximal_count=True it is not possible to select more options than allowed.

It should be possible to select more options than allowed and display an error message when trying to confirm, to be consistent to minimal_count=True.
Alternatively a message could be flashed when the user tries to select an option, but maximal_count is reached. This way a user would at least get some feedback.

Apart from that, this means theres some unreachable code here and there.

Functions like select will exit the CLI if an unrecognized key is pressed.
Because of this, select not only will exit on ENTER, but also on any other key that is not UP or DOWN. This could be potentially be frustrating if the user is 10 sections down in a dialog and has to start over again, just because he pressed RIGHT instead of UP.

I suggest to just ignore these inputs and only react to the available options.

I have made the selection and multi-selection function scrollable. I didn't want to make a PR right now because my changes are not super nice. But if someone needs the function, he can get it from my repo: https://github.com/C0D3D3V/Moodle-Downloader-2/blob/main/moodle_dl/utils/cutie.py

When using select_multiple with hide_confirm=True, no error messages are displayed.

The issue lies here and could be solved by altering the message in a seperate if hide_confirm branch and then printing it, instead of putting the complete message printing in a if hide_confirm branch.