At Thu, 1 Apr 2010 18:26:52 +0200 (CEST), Magnus Eriksson
<magetoo%fastmail.fm@localhost> wrote:
Subject: Re: The Chthulhoid horror that is keyboard handling in Unix (Re:
Backspace, Delete and other keys)
>
> On Thu, 1 Apr 2010, Greg A. Woods wrote:
> >
> > We _do_ still have to do all this low-level stuff though, right down to
> > the way bits are represented and transmitted electrically or whatever.
>
> Yes, absolutely. There are some things we don't have to do though, like
> VTnn emulation, and expressing everything in terms of 7/8-bit characters.
However somewhere we do still need to go between keysyms or scancodes or
whatever and characters in some representation useful for programs that
deal with input and output in a character oriented way.
> One thing I've been thinking about is whether one could write a "terminal"
> for X that doesn't suck; something to replace the terminal emulators we
> all use, but that doesn't emulate 40-year old hardware. It works for
> graphical toolkits after all, they deal directly with keysyms[*] without
> having to go the route of converting everything to an 8-bit code before
> passing keystrokes to the intended program, and I don't see any obvious
> reason why any command line interface couldn't do the same.
Do you not see there's a major catch-22 there in your idea?
I think the closest you could come is something like Plan 9's 8.5 or rio.
Ultimately you still have to interact with programs using
character-based input and output, at least in the unix/posix world.
For output if you don't have some kind of terminal emulation using
in-band control sequences (eg. VT100/ANSI/ECMA-48) then you have to
re-write all those applications which want to do something more
sophisticated than just scroll text by on the screen to use some other
form of control, such as drawing pixels directly as in Plan 9 rio.
Similarly for input -- you can have the window or window system
interpret all the keysyms and then have a key which sends the text in
the window to the application (like Plan 9's 8.5 window system), and
then your applications can only accept plain text input, or else you
have to have some kind of in-band control sequences to translate your
keysyms into control codes for the application, or you need some
separate communications channel for the application to read keysyms
directly.
Ultimately you still have the task of mapping whatever the keyboard
controller gives you into those keysyms and given every keyboard seems
to have a different layout then you still need some means of mapping
keyboard controller codes into standard keysyms understood by your
system.
If you totally escape the unix/posix mindset then you can achieve the
kind of thing you were describing. Indeed Apple have already been doing
this kind of thing for decades now, but note they don't have programs
which interact with text input and output (until recently when they
replaced their OS with a unix-like one and now they have a traditional
terminal emulation program and all the termcap/terminfo/libcurses stuff
that goes along with it).
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218 0099 http://www.planix.com/
Attachment:
pgpHibZsb4Nbt.pgp
Description: PGP signature