gh-81163: Add support for extended color functions in ncurses 6.1 - #17536
Conversation
|
I signed the CLA earlier today, hopefully it shows up in the system soon. |
|
Hi, May I ask what is the status of this fix ? Thanks. |
|
Thanks for the review. I've addressed the issues brought up so far and a few more I found, and rebased it on master. |
|
Alas, soon after the PR was updated, a large change across a number of modules relating to argument processing was merged by @serhiy-storchaka (578c395 for bpo-37999) that now causes merge conflicts for this PR. It would also be nice to merge this to 3.9 but there seem to be other merge conflicts there. Perhaps after fixing the merge conflicts here, a 3.9 backport PR could be prepared. |
…t using the extended color functions in ncurses 6.1 when available. color_content color_number init_color init_pair
…ons to make them simpler and more maintainable
…, so use #if instead of #ifdef.
…ndicate whether extended colors are suported by the underlying ncurses library.
Use preconditions to ensure it's in range.
This got lost during the rebase. Also change versionadded from 3.8 to 3.10.
|
I have made the requested changes; please review again. @websurfer5 Since this is your work originally, I gave you access to my fork -- feel free to change it as you like. |
|
Thanks for making the requested changes! @ned-deily: please review the changes made to this pull request. |
ned-deily
left a comment
ned-deily
left a comment
There was a problem hiding this comment.
Thanks for adding the doc change.
I built and ran test_curses on macOS with both the system ncurses 5.x and with a current ncurses 6.2 and verified that the current test_curses fails with 6.2 and that, with the PR applied, test_curses passes with both versions of ncurses and that has_extended_color_support() returns the expected values.
…ythonGH-17536) Co-authored-by: Jeffrey Kintscher <websurfer@surf2c.net>
|
Nice ! thank you all for your work and efforts ! |
|
Thanks for fixing this! |
|
Thanks @hpjansson for the PR, and @ned-deily for merging it 🌮🎉.. I'm working now to backport this PR to: 3.9. |
|
Sorry, @hpjansson and @ned-deily, I could not cleanly backport this to |
…ythonGH-17536) Co-authored-by: Jeffrey Kintscher <websurfer@surf2c.net>
…ythonGH-17536) Co-authored-by: Jeffrey Kintscher <websurfer@surf2c.net>
terryjreedy
changed the title
11 participants
This is a rebase of @websurfer5's #13534 against master, since that PR no longer applies cleanly and has not been updated since May. It now appears to pass the check that was failing in #13534 (review).
The original description from @websurfer5's PR follows.
ncurses 6.1 adds extended color functions to support terminals with 256 colors (e.g. xterm-256color). The extended functions use color-pair values that are signed integers because the existing functions only use signed short integer values that are too small to support the 65,536 color-pair values needed for a 256-color terminal.
The new extended color functions are used transparently by curses.color_content(), curses.init_color(), curses.init_pair(), and curses.pair_content() when available, and the original functions are used when they aren't. The module functions validate their parameters as signed integers when using the new extended functions and as signed short integers when using the original library functions to match the underlying ncurses function parameters. The original behavior remains unchanged when Python is built with a curses library that does not contain the new extended color functions.
A new function, curses.has_extended_color_support(), indicates whether extended color support is provided by the underlying ncurses library.
This PR also fixes issue #36630.