开发者

Keys not being interpreted by ncurses

I have a curses based application (WordGrinder). I've just had a bug report from a user saying that some keys aren't working properly on his keyboard. On investigation, he's right.

The keys in question are SHIFT+cursor keys and some of the keypad navigation keys, such as END. Investigating what's going on, it seems that curses is not sending me events for these keys. In the case of SHIFT+cursor keys, I'm not getting anything at all, and for END I'm getting a raw escape sequence.

This surprises me. All the other keys are getting interpreted and translated correctly into keysyms. I'd expect to be getting KEY_SLEFT and KEY_END. Why aren't I?

I've looked at some other applications where these keys work but don't spot anything obvious that I'm doing wrong; and applications like nano do really evil things like handle their own escape key parsing anyway, so I don't know if they're a good candidate for source code.

I'm initialising ncurses as follows:

initscr();
raw();
noecho();
meta(NULL, TRUE);
nonl();
idlok(stdscr, TRUE);
idcok(stdscr, TRUE);
scrollok(stdscr, FALSE);
intrflush(stdscr, FALSE);
keypad(stdscr, TRUE开发者_开发问答);

I'm using gnome-terminal as the terminal emulator, and xterm as the terminal type. Locale is UTF-8 and I've got the ncursesw variant of the library.

Any ideas?

Update:

Well, many months later I try Wordgrinder with Gnome 3's gnome-terminal and discover that all these wacky keys generate valid ncurses keycodes. For example, SHIFT+LEFT now produces keycode 393. xterm produces exactly the same result. Unfortunately, CTRL+LEFT produces keycode 539, and the Curses documentation states clearly that valid keycodes are in the range KEY_MIN to KEY_MAX --- 257 to 511...

So at least things work now, but how do these weird new keycodes work? Are they defined anywhere? They're certainly not in the headers.


gnome-terminal is not an xterm. It sends different combinations for shift-arrow and control-arrow. With ncurses version 5.5 setting TERM to gnome will probably work.

Here is some information: http://invisible-island.net/xterm/xterm.faq.html#bug_gnometerm


There's a good chance that gnome-terminal is intercepting your SHIFT-arrow keys for its own purposes. I would suggest running your application in xterm or from the console.


I have done a raw [ cfmakeraw ] STDIN scan using EPOLL. And I can confirm that SHIFT+LEFT; SHIFT+RIGHT; are NOT "scanned". So how does XLib client read those keys ?

XLib client/driver uses direct keyboard drivers (using good old BIOS's multiplex Hardware INTERRUPT hooks)...There are no other ways to "scan" [Forgotten RAW] keyboard state ) :-)

NCurses is a client of the serial /dev/TTY* for the obvious networking reasons - Not a hardware hook.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜