Today I checked in a new version of the curses module that will only work with ncurses and/or SYSV curses. I've tried compiling it on Linux with ncurses 5.0, and on Solaris; there are also #ifdef's to make it work with some version of SGI's curses. I'd appreciate it if people could try the module with the curses implementations on other platforms: Tru64, AIX, *BSDs (though they use ncurses, maybe they're some versions behind), etc. Please let me know of your results through e-mail. And if you have code that used the old curses module, and breaks with the new module, please let me know; the goal is to have 100% backward-compatibility. Also, here's a list of ncurses functions that aren't yet supported; should I make adding them a priority. (Most of them seem to be pretty marginal, except for the mouse-related functions which I want to add next.) addchnstr addchstr chgat color_set copywin define_key del_curterm delscreen dupwin getmouse inchnstr inchstr innstr keyok mcprint mouseinterval mousemask mvaddchnstr mvaddchstr mvchgat mvcur mvinchnstr mvinchstr mvinnstr mmvwaddchnstr mvwaddchstr mvwchgat mvwgetnstr mvwinchnstr mvwinchstr mvwinnstr napms newterm overlay overwrite resetty resizeterm restartterm ripoffline savetty scr_dump scr_init scr_restore scr_set scrl set_curterm set_term setterm setupterm slk_attr slk_attr_off slk_attr_on slk_attr_set slk_attroff slk_attron slk_attrset slk_clear slk_color slk_init slk_label slk_noutrefresh slk_refresh slk_restore slk_set slk_touch tgetent tgetflag tgetnum tgetstr tgoto tigetflag tigetnum tigetstr timeout tparm tputs tputs typeahead ungetmouse use_default_colors vidattr vidputs waddchnstr waddchstr wchgat wcolor_set wcursyncup wenclose winchnstr winchstr winnstr wmouse_trafo wredrawln wscrl wtimeout -- A.M. Kuchling http://starship.python.net/crew/amk/ ..signature has giant ASCII graphic: Forced to read "War And Peace" at 110 baud on a Braille terminal after having fingers rubbed with sandpaper. -- Kibo, in the Happynet Manifesto
Andrew M. Kuchling
Also, here's a list of ncurses functions that aren't yet supported; should I make adding them a priority. (Most of them seem to be pretty marginal, except for the mouse-related functions which I want to add next.)
addchnstr addchstr chgat color_set copywin define_key del_curterm delscreen dupwin getmouse inchnstr inchstr innstr keyok mcprint mouseinterval mousemask mvaddchnstr mvaddchstr mvchgat mvcur mvinchnstr mvinchstr mvinnstr mmvwaddchnstr mvwaddchstr mvwchgat mvwgetnstr mvwinchnstr mvwinchstr mvwinnstr napms newterm overlay overwrite resetty resizeterm restartterm ripoffline savetty scr_dump scr_init scr_restore scr_set scrl set_curterm set_term setterm setupterm slk_attr slk_attr_off slk_attr_on slk_attr_set slk_attroff slk_attron slk_attrset slk_clear slk_color slk_init slk_label slk_noutrefresh slk_refresh slk_restore slk_set slk_touch tgetent tgetflag tgetnum tgetstr tgoto tigetflag tigetnum tigetstr timeout tparm tputs tputs typeahead ungetmouse use_default_colors vidattr vidputs waddchnstr waddchstr wchgat wcolor_set wcursyncup wenclose winchnstr winchstr winnstr wmouse_trafo wredrawln wscrl wtimeout
I think you're right to put the mouse support at highest priority. I'd say napms() and the overlay/overwrite/copywin group are moderately important. So are the functions in the curs_inopts(3x) group -- when you need those, nothing else will do. You can certainly pretty much forget the slk_* group; I only implemented those for the sake of excruciating completeness. Likewise for the mv* variants. Here's a function that ought to be in the Python wrapper associated with the module: def traceback_wrapper(func, *rest): "Call a hook function, guaranteeing curses cleanup on error or exit." try: # Initialize curses stdscr=curses.initscr() # Turn off echoing of keys, and enter cbreak mode, # where no buffering is performed on keyboard input curses.noecho() ; curses.cbreak() # In keypad mode, escape sequences for special keys # (like the cursor keys) will be interpreted and # a special value like curses.KEY_LEFT will be returned stdscr.keypad(1) # Run the hook. Supply the screen window object as first argument apply(func, (stdscr,) + rest) # Set everything back to normal stdscr.keypad(0) curses.echo() ; curses.nocbreak() curses.endwin() # Terminate curses except: # In the event of an error, restore the terminal # to a sane state. stdscr.keypad(0) curses.echo() ; curses.nocbreak() curses.endwin() traceback.print_exc() # Print the exception (Does this case mean, perhaps, that the Python interper ought to allow setting a stack of hooks to be executed just before traceback-emission time?) I'd also be willing to write a Python function that implements Emacs-style keybindings for field editing, if that's interesting. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> Don't think of it as `gun control', think of it as `victim disarmament'. If we make enough laws, we can all be criminals.
Eric S. Raymond writes:
Here's a function that ought to be in the Python wrapper associated with the module:
There currently is no such wrapper, but there probably should be. Guess I'll rename the module to _curses, and add a curses.py file. Or should there be a curses package, instead? That would leave room for more future expansion. Guido, any opinion? --amk
On Wed, 24 May 2000, Andrew Kuchling wrote:
Eric S. Raymond writes:
Here's a function that ought to be in the Python wrapper associated with the module:
Dang. Deleted Eric's note accidentally. Note that the proposed wrapper can be simplifed by using try/finally.
There currently is no such wrapper, but there probably should be. Guess I'll rename the module to _curses, and add a curses.py file. Or should there be a curses package, instead? That would leave room for more future expansion. Guido, any opinion?
Just a file. IMO, a package would be overkill. Cheers, -g -- Greg Stein, http://www.lyra.org/
There currently is no such wrapper, but there probably should be. Guess I'll rename the module to _curses, and add a curses.py file. Or should there be a curses package, instead? That would leave room for more future expansion. Guido, any opinion?
Whatever -- either way is fine with me! --Guido van Rossum (home page: http://www.python.org/~guido/)
Andrew Kuchling
Eric S. Raymond writes:
Here's a function that ought to be in the Python wrapper associated with the module:
There currently is no such wrapper, but there probably should be. Guess I'll rename the module to _curses, and add a curses.py file. Or should there be a curses package, instead? That would leave room for more future expansion. Guido, any opinion?
I'll supply a field-editor function with Emacs-like bindings, too. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> Never trust a man who praises compassion while pointing a gun at you.
On Wed, 24 May 2000, Andrew Kuchling wrote:
There currently is no such wrapper, but there probably should be. Guess I'll rename the module to _curses, and add a curses.py file. Or should there be a curses package, instead? That would leave room for more future expansion. Guido, any opinion?
I think a package makes sense; some of the libraries that provide widget sets on top of ncurses would be prime candidates for inclusion. The structure should probably be something like: curses/ __init__.py # from _curses import *, docstring _curses.so # current curses module ... -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>
participants (6)
-
Andrew Kuchling
-
Andrew M. Kuchling
-
Eric S. Raymond
-
Fred L. Drake
-
Greg Stein
-
Guido van Rossum