[GRASSLIST:5658] Re: arrow keys not working

GRASS GRASS user
1

Glynn,

From: Glynn Clements <glynn.clements@virgin.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
To: Wayne Gibson <gibson@coas.oregonstate.edu>
Cc: grasslist@baylor.edu
Subject: Re: [GRASSLIST:5655] arrow keys not working

Wayne Gibson wrote:

After compiling on a SUN, the cursor keys are not working in the
window where the user interactively can set LOCATION, MAPSET, and
DATABASE. I believe this is generated from "etc/set_data". By the
way, this is the same program that experienced compiling problems
before due to the curses library and since fixed (at least I thought
so).

Look at the HAVE_KEYPAD line in src/include/config.h. If the macro is
undefined, then your curses library doesn't support the use of cursor
keys (at least, configure failed to detect the keypad() function). If
the macro is defined, then either it's a bug in the curses library, or
xterm's termcap/terminfo entry is broken.

The macro is define.

In addition, I tested out the ncurses library with the supplied test program
"ncurses", option "a"( keyboard and mouse input test). The arrow keys are
correctly mapped as:

0405 KEY_RIGHT
0403 KEY_UP
0404 KEY_LEFT
0402 KEY_DOWN

Also, the same test program with option "g"(display windows and scrolling)
correctly allows me to move around the screen with the arrow keys.

I compared the libraries required by "set_data" in the 5.0.0 pre-compiled
version and 5.0.1 that I compiled. The pre-compiled uses both libncurses and
libcurses while the version I compiled uses libncurses only. It that what one
should expect? (5.0.0 "set_data" works)

BTW, Ctrl-K should have the same effect as the up-arrow key, Ctrl-L
the same effect as the right-arrow key, and Return/LineFeed the same
as the down-arrow key; there isn't an exact equivalent to the
left-arrow key.

It would be great to have both left and right arrow keys working. Those are the
2 I use the most.

After I enter <ESC><ENTER> and proceed to working in the GRASS
terminal window, then the cursor keys start working again.

Bash doesn't use curses; it has it's own ad-hoc mechanism for handling
extended keys.

GRASS uses the standard curses interface, i.e. it calls keypad() to
enable the cursor keys, then processes the extended codes (KEY_LEFT
etc) which the curses library should generate for extended keys.

If curses fails to process the keys correctly, then they won't work.

--
Glynn Clements <glynn.clements@virgin.net>

Wayne

-----------------------
Wayne Gibson
Oregon State University
gibson@coas.oregonstate.edu
(541) 737-5696

2

Wayne Gibson wrote:

I compared the libraries required by "set_data" in the 5.0.0 pre-compiled
version and 5.0.1 that I compiled. The pre-compiled uses both libncurses and
libcurses while the version I compiled uses libncurses only. It that what one
should expect? (5.0.0 "set_data" works)

I've figured out what's happening.

Short version: add:

  #include "config.h"

to the top of src/libes/vask/V_init.c and re-compile (the problem is
in a library, so I suggest compiling from scratch).

Long version:

1. 5.0.0 didn't have the test for HAVE_KEYPAD; it always used
keypad(), which resulted in a compilation failure on systems where
the curses library didn't have the keypad() function.

2. 5.0.1 has the keypad() check in configure, and HAVE_KEYPAD in
src/include/config.h[.in], and the use of keypad() is conditionalised
upon HAVE_KEYPAD. Unfortunately, the source file neglected to actually
include config.h, so keypad() was never used and the cursor keys won't
work.

3. The problem is fixed in the current CVS versions (both HEAD and the
release branch from which 5.0.2 will be built); actually, the problem
had already been fixed in the CVS HEAD when 5.0.1 was released, but it
hadn't been merged into the release branch at that point.

--
Glynn Clements <glynn.clements@virgin.net>