feat(!): Major rework to blessed
Info
This would somewhat address and/or entirely close:
- https://github.com/aisk/pick/issues/108
- https://github.com/aisk/pick/issues/83
- https://github.com/aisk/pick/issues/58
- https://github.com/aisk/pick/issues/29
- https://github.com/aisk/pick/issues/21
- https://github.com/aisk/pick/issues/111
- https://github.com/aisk/pick/issues/48
Changes
- Changes over to using blessed for the screen writing
- Adds support for easier colored text
- Makes un-selectable options (via setting the
Option'senablevalue toFalse) visually distinct to show un-selectable- Will render the value in the selection list as a greyed out value, and won't allow selecting it
- Adds the ability to filter by typing
- Any key letter key thats not up/down/exit goes to filter, which is displayed at the top
- If no values match the current filter, warning message is displayed to remove filter constriction
- Any key letter key thats not up/down/exit goes to filter, which is displayed at the top
TODO:
~~1. Increased flexibility for coloring options?~~
Can specify a color to an Option() now, as well as specifying the disabled color and pagination tip colors to pick(); in addition, because not using curses, ansi codes can be used anywhere and interpreted appropriately.
~~2. Ensure closer parity to existing pick library currently~~
~~* Biggest gap is the existing screen option; don't know that that would be even possible to do while leveraging blessed? It seems not likely, unless I'm missing something.~~
~~* Notably: the example/position.py is the only example that is not working equivalently~~
I'm convinced that switching to blessed entirely breaks interoperability with curses - this would need to be a discussion, I think? for this reason, I've set it to a major version upgrade - though I fear that this change will disrupt a good group of people who chose this package (bc they already had a curses app and wanted a nice pre-built menuing utility)? I am unsure what percentage of people that use this package absolutely require it to be interoperable with curses, but by going to blessed, I am of the opinion that it removes that option completely.
- ???
I would appreciate any further input/thoughts as well, thanks!
demo
- Multi-pick, showing enforced pick number + selecting/un-selecting
- Single-pick, with filter
- Scroll case, with filter including too restrictive filter
~~The pagination/scrolling still needs some work; The chunking approach won't always work because if you have a particularly long line(s), they can wrap over and take up more than one line vertically, and that messes up that approach~~
I'm not sure whether we should switch to blessed or not, but in my opinion, it's not good to add too many features in one PR. Maybe we can split the enhancement parts into other small PRs if possible. If they are coupled with blessed, we can add them later.
I don't know if we can make the backend (curses or blessed) selectable, so the user can specify using curses for existing TUI apps.