[Gambas-user] Ncurses Trapping Shift Tab issue when not run under X

Tobias Boege taboege at gmail.com
Fri Jul 19 19:09:36 CEST 2019

On Fri, 19 Jul 2019, KKing wrote:
> the below, appears to yield different results when run in unit not running X
>  iKey = $hText.Read(1000)
> When run either in IDE or the executable run within a terminal started under
> X (e.g. XTerm or LXTerminal) iKey contains 353
> BUT when run on unit with no X, it return just 9  (i.e. it has disregarded
> the SHIFT being held.
> thoughts?

Decimal 353 is KEY_BTAB, or "back tab". I have no idea what this key
is supposed to be doing and in my text editor it just causes a regular
tab to be inserted. The terminals you use under X (as well as Konsole
and urxvt over here) seem to have the idea that Shift+Tab should mean
"back tab" and they send this key to the application. The terminal
you use under non-X (the Linux console?) has a different idea and
just sends a tab which is decimal 9.

If you look at the output of `xev` when you type a Tab vs. a Shift+Tab,
you see that X considers them as different keys (Tab vs. ISO_Left_Tab).
In my .Xmodmap, I can map the keycode 23 generated by Shift+Tab to some
other letter and sure enough that's the letter received by Window.Read
in gb.ncurses.

In short: I think the difference lies between those parts of the system
that process keyboard events and turn them into input keys for the program.
Under X, that is X (which is also why all X terminals behave the same),
but in the Linux console, this is the Linux keyboard/terminal driver.
Anyway, all this happens before even ncurses or gb.ncurses get involved,
so no dice.


"There's an old saying: Don't change anything... ever!" -- Mr. Monk

More information about the User mailing list