[ipxe-devel] minor issues with the full-screen UI

Ivan Shmakov oneingray at gmail.com
Tue Aug 21 17:40:58 UTC 2012


	While testing the latest menu patch, I've also noticed that
	while KEY_PPAGE, KEY_NPAGE work for CONSOLE_SERIAL (for a
	GNU Screen window under a Linux VT), KEY_HOME & KEY_END do not.
	Indeed, there's no standard for encoding functional keys like
	those (which is the whole point of having terminfo(5), BTW.)

	To solve this, I guess that along with the current KEY_UP,
	etc. keyboard sequences, some Ctrl+Alpha ones could be bound to
	the same functions (as the latter are always encoded in the same
	way — by masking all but the lower five bits of the
	corresponding alphabetical character's ASCII code.)  My
	suggestion would be to reuse GNU Readline (and thus well-known)
	bindings, like:

    KEY_UP	CTRL_P		prior element;
    KEY_DOWN	CTRL_N		next  element;
    KEY_HOME	CTRL_A		first element;
    KEY_END	CTRL_E		last  element.

	Interfaces based on GNU Readline don't typically provide
	functions for page-wise scrolling, but GNU Emacs (whose bindings
	were the basis for GNU Readline bindings) does, so it could be:

    KEY_NPAGE	CTRL_V

	Unfortunately, scrolling the other way is bound to M-v in Emacs,
	which could be encoded as either ESC v or 0366, depending on the
	terminal settings (consider, e. g., the metaSendsEscape option
	to XTerm.)  OTOH, C-v may be just enough if it's allowed to
	wrap-around.

	Still, I wonder if there could be any harm in allowing for the
	key bindings to be customized via the already-suggested
	config/tui.h configuration file?  Like:

#define MENU_UP		KEY_UP
#define MENU_UP_ALT	CTRL_P

#include <config/local/tui.h>

/* allow alternative keys to be disabled with #undef */
#ifndef MENU_UP_ALT
#define MENU_UP_ALT	MENU_UP
#endif

	It'd also make sense to reuse these defines in settings_ui.c
	(which currently lacks support for KEY_HOME, KEY_PPAGE, etc.,
	BTW.)

	Finally, serial communication may be not as reliable as the one
	done via PC “console.”  For a variety of reasons, the screen may
	end up being screwed.  Thus, it may make sense to allow for yet
	another key sequence (e. g., C-l) to force a redraw.

-- 
FSF associate member #7257	http://sf-day.org/




More information about the ipxe-devel mailing list