Re: [PDCurses] key mappings
Thank you. I see what you mean: the get_wch() method looks as if it's applicable to ncurses and all PDCurses... in other words, pretty much everything. The SP->key_code method, and the method Florian and I used in Win32a, will only work in PDCurses. (Unless we persuaded the ncurses people to change their ways. And even then, you'd have the old libraries out there. So get_wch() wins.) I don't see much need to revise my code, but I'll add a note to the effect that "while this works, you're better off using get_wch() and checking the return value." -- Bill On 04/08/2015 06:28 PM, William McBrine wrote: On Wed, Apr 8, 2015 at 5:17 PM, Bill Gray wrote: Incidentally, you'll also see that in the Win32a version of 'curses.h', the return values are relative to KEY_OFFSET. The reason for this is that PDCurses' "usual" values assume a non-wide version, and they start at 0x100. Try making a Unicode build, and there will be collisions: if you get, say, 0x16B, did your user hit KEY_MESSAGE, or an 's with acute accent'? Florian Große-Coosmann wrote to me about this a while back. Here's what I said then: It's not necessary to relocate the key definitions in order to distinguish the control keys from regular Unicode input. One must simply use get_wch() instead of getch(), and check the return value (KEY_CODE_YES or OK), as well as the character result (which is placed at the location given by the parameter). Alternatively, if you don't care about using standard curses wide-character functions, you can continue using getch(), but check the PDCurses-specific SP->key_code to determine whether or not the result is a "special" key. However, I recommend get_wch(). These capabilities date to 2006, BTW.
Re: [PDCurses] key mappings
On Wed, Apr 8, 2015 at 5:17 PM, Bill Gray wrote: >Incidentally, you'll also see that in the Win32a version of 'curses.h', > the return values are relative to KEY_OFFSET. The reason for this is that > PDCurses' "usual" values assume a non-wide version, and they start at > 0x100. Try making a Unicode build, and there will be collisions: if you > get, say, 0x16B, did your user hit KEY_MESSAGE, or an 's with acute > accent'? > Florian Große-Coosmann wrote to me about this a while back. Here's what I said then: It's not necessary to relocate the key definitions in order to distinguish the control keys from regular Unicode input. One must simply use get_wch() instead of getch(), and check the return value (KEY_CODE_YES or OK), as well as the character result (which is placed at the location given by the parameter). Alternatively, if you don't care about using standard curses wide-character functions, you can continue using getch(), but check the PDCurses-specific SP->key_code to determine whether or not the result is a "special" key. However, I recommend get_wch(). These capabilities date to 2006, BTW.
Re: [PDCurses] key mappings
Hi Laura, As you found, there's no real consistency among implementations as to the exact values. Try to write something that works with both PDCurses and ncurses, for example, and you'll have some code that looks like #ifdef KEY_EXIT if( key == KEY_EXIT) do_stuff( ); #endif #ifdef KEY_B3 if( key == KEY_B3) do_b3_stuff( ); #endif I see I have an '#ifdef ALT_0' in one bit of code, so even that cannot be uniformly relied upon. Now, in terms of what we _should_ do... I guess I'd rather like the idea that we minimize the number of keys. Rather than have an 'A' and an 'Alt-A', you'd have an A with the Alt modifier set. I say that despite having added a hundred or so key codes to the Win32a flavor of 'curses.h' (look in that file for the section starting with CTL_SEMICOLON). I figure that if we have all these keys (I have a keyboard with 'browser back/forward', 'refresh', 'search', etc. keys), we ought to be able to access them. But I do have KEY_VOLUME_DOWN, KEY_SVOLUME_DOWN, KEY_CVOLUME_DOWN, and KEY_AVOLUME_DOWN as four separate key codes. Incidentally, you'll also see that in the Win32a version of 'curses.h', the return values are relative to KEY_OFFSET. The reason for this is that PDCurses' "usual" values assume a non-wide version, and they start at 0x100. Try making a Unicode build, and there will be collisions: if you get, say, 0x16B, did your user hit KEY_MESSAGE, or an 's with acute accent'? Further details at http://projectpluto.com/win32a.htm#2014mar1 , but essentially, we put the KEY_ values into Unicode's Private Use Area, where it cannot collide with any actual key value somebody using an Absurdistani keyboard layout might generate. -- Bill On 04/08/2015 03:35 PM, LM wrote: I'm trying to double-check that the keys are mapping properly for SDL. The only documentation on keys that I could turn up was at: http://pubs.opengroup.org/onlinepubs/7908799/xcurses/curses.h.html Does anyone have a list of what key values should be returned for what key combinations. curses.h has some values defined such as ALT_0 - ALT_9 and ALT_A - ALT_Z. A curses application like hexedit uses CONTROL_A - CONTROL_Z and CONTROL_SLASH which aren't even documented by pdcurses. Checking the various back-ends of pdcurses, even its key translations don't seem to agree with each other. Some pdcurses back-ends return ALT_BSLASH and some return the backslash with alt modifier set. Does anyone know where to find documentation on what should be valid key return values or does anyone have recommendations on how they'd like to see this consistently handled? It would be nice to have better compatibility with what ncurses does if possible. Thanks.
Re: [PDCurses] key mappings
ncurses doesn't handle most of these keys at all. And anything beyond what you see in the Open Group spec is non-standard, by definition. Control-A through Control-Z are actually standard ASCII,1 through 26. On Wed, Apr 8, 2015 at 3:35 PM, LM wrote: > I'm trying to double-check that the keys are mapping properly for SDL. > The only documentation on keys that I could turn up was at: > http://pubs.opengroup.org/onlinepubs/7908799/xcurses/curses.h.html > > Does anyone have a list of what key values should be returned for what > key combinations. curses.h has some values defined such as ALT_0 - > ALT_9 and ALT_A - ALT_Z. A curses application like hexedit uses > CONTROL_A - CONTROL_Z and CONTROL_SLASH which aren't even documented > by pdcurses. Checking the various back-ends of pdcurses, even its key > translations don't seem to agree with each other. Some pdcurses > back-ends return ALT_BSLASH and some return the backslash with alt > modifier set. > > Does anyone know where to find documentation on what should be valid > key return values or does anyone have recommendations on how they'd > like to see this consistently handled? It would be nice to have > better compatibility with what ncurses does if possible. Thanks. >
