question about gcc and keyboard hadling

question about gcc and keyboard hadling

[+Rudymartin]

hi folks 

im trying to develop a text editor using gcc version 2.96 20000731 (Red Hat 
Linux 7.1 2.96-81) , and thats because I want to make some experience with 
C++ (I used to program in Java and C under windowz) The Info pages have 
information about most libraries and functions but I have found no way to 
trap the modifiers keys (ALT/CTRL/SHIFT) under a terminal. And I noticed 
emacs can trap those keys under a terminal.

I tried using the ncurses library and termcap.

Where I can find some information about that? 

btw sry my english isnt perfect. thanks in advance. Rudy.

Re: question about gcc and keyboard hadling

[Glynn Clements]

+Rudymartin wrote:

> im trying to develop a text editor using gcc version 2.96 20000731 (Red Hat 
> Linux 7.1 2.96-81) , and thats because I want to make some experience with 
> C++ (I used to program in Java and C under windowz) The Info pages have 
> information about most libraries and functions but I have found no way to 
> trap the modifiers keys (ALT/CTRL/SHIFT) under a terminal. And I noticed 
> emacs can trap those keys under a terminal.

You can't get the same kind of modifier behaviour on a terminal that
you can in a windowed environment.

You can only detect Control and Shift to the extent that they affect
the character code. And you can't tell the difference between
different ways of generating the same code, e.g. Ctrl-M and Return or
Ctrl-I and Tab.

Also, there are two ways in which Meta/Alt is handled. One way is to
add 128 to the code, the other way is to precede the code by ESC (code
27). AFAICT, Emacs only handles ESC-<code>.

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

Re: question about gcc and keyboard hadling

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]

On Mon, 2002-08-05 15:43:18 +0100, Glynn Clements <glynn.clements@virgin.net>
wrote in message <15694.36614.996185.222692@cerise.nosuchdomain.co.uk>:
> 
> +Rudymartin wrote:
> 
> > im trying to develop a text editor using gcc version 2.96 20000731 (Red Hat 
> > Linux 7.1 2.96-81) , and thats because I want to make some experience with 
> > C++ (I used to program in Java and C under windowz) The Info pages have 
> > information about most libraries and functions but I have found no way to 
> > trap the modifiers keys (ALT/CTRL/SHIFT) under a terminal. And I noticed 
> > emacs can trap those keys under a terminal.
> 
> You can't get the same kind of modifier behaviour on a terminal that
> you can in a windowed environment.

Well... It's not exactly portable, but you (at least) can get Ctrl, Alt
and Shift running Linux at the Console. I don't know in which way this
interacts with ncurses (definitely, it _will_ interact on input), but
you can do eg.:

#include <stdio.h>
#include <fcntl.h>
#include <linux/kd.h>
#include <possibly/others.h>

struct termios tio_old;
struct termios tio_new;
int old_mode;
char one_byte;

fd=open("/dev/tty", O_RDONLY);
tcgetattr(fd, &tio_old);
tcgetattr(fd, &tio_new);
ioctl(fd, KDGKBMODE, &old_mode);
ioctl(fd, KDSKBMODE, K_MEDIUMRAW);
tio_new.c_lflag	&= ~(ICANON|ECHO|ISIG);
tio_new.c_iflag = 0;
tio_new.c_cc[VMIN] = 1;
tio_new.c_cc[VTIME] = 1
tcsetattr(fd, TCSANOW, &tio_new);
tcflush(fd, TCIOFLUSH);

while(read() == sizeof(one_byte)) {
	/* Process Input, will show Alt, Shift and Ctrl*/;
	if(dont_need_to_do_more_work)
		break;
}

ioctl(fd, KDSKBMODE, old_mode);
tcsetattr(fd, TCSANOW, &tio_old);
tcflush(fd, TCIOFLUSH);

close(fd);

However - not easily portable:-(

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: question about gcc and keyboard hadling

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

On Mon, 2002-08-05 15:43:18 +0100, Glynn Clements <glynn.clements@virgin.net>
wrote in message <15694.36614.996185.222692@cerise.nosuchdomain.co.uk>:
> +Rudymartin wrote:
> > im trying to develop a text editor using gcc version 2.96 20000731 (Red Hat 
> > Linux 7.1 2.96-81) , and thats because I want to make some experience with 
> > C++ (I used to program in Java and C under windowz) The Info pages have 
> > information about most libraries and functions but I have found no way to 
> > trap the modifiers keys (ALT/CTRL/SHIFT) under a terminal. And I noticed 
> > emacs can trap those keys under a terminal.
> 
> You can't get the same kind of modifier behaviour on a terminal that
> you can in a windowed environment.

Even better question: I'd like to work on a text-based application and
I'd like to act on simply pressing eg. Ctrl (change some context menu).
I can do this with the hack I just posted nicely, but it will fail when
running under X11. Is there any possibility in getting a callback
registered called everytime an event occures which affects my terminal
emulation's window? There, I could fetch the modifiers...

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: question about gcc and keyboard hadling

[Glynn Clements]

Jan-Benedict Glaw wrote:

> Even better question: I'd like to work on a text-based application and
> I'd like to act on simply pressing eg. Ctrl (change some context menu).
> I can do this with the hack I just posted nicely, but it will fail when
> running under X11. Is there any possibility in getting a callback
> registered called everytime an event occures which affects my terminal
> emulation's window?

No, there isn't.

An application which uses terminal I/O is inherently limited by the
set of actions for which the terminal actually generates input.

If you want behaviour that isn't provided by most terminals, then use
X instead. At least X is portable, unlike ioctl(KDSKBMODE) or
terminal-specific behaviours.

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

About combined console/X11 programs (was: question about gcc and keyboard hadling)

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

On Tue, 2002-08-06 17:22:57 +0100, Glynn Clements <glynn.clements@virgin.net>
wrote in message <15695.63457.98209.624871@cerise.nosuchdomain.co.uk>:
> 
> Jan-Benedict Glaw wrote:
> 
> > Even better question: I'd like to work on a text-based application and
> > I'd like to act on simply pressing eg. Ctrl (change some context menu).
> > I can do this with the hack I just posted nicely, but it will fail when
> > running under X11. Is there any possibility in getting a callback
> > registered called everytime an event occures which affects my terminal
> > emulation's window?
> 
> No, there isn't.
> 
> An application which uses terminal I/O is inherently limited by the
> set of actions for which the terminal actually generates input.

Think different. Think of linking mentioned application against
xlibs/gtk+/whatever. Then, if(getenv("DISPLAY")) you could init the X11
client side. This way, you can work on console (using so far Linux'isms)
_and_ you can work under X11 within _one_ binary. What now is the point
is to fetch all the events which are ment to out xterm's window.

So, if you're running on console (!getenv("DISPLAY")), you initialize
your input routine using ioctl(), but if running under X11, you
initialize needed xlibs. The remaining problems then is to fetch the
right events. I currently see no easy way in doing this, but there of
course must be some:-}

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: About combined console/X11 programs (was: question about gcc and keyboard hadling)

[Glynn Clements]

Jan-Benedict Glaw wrote:

> > > Even better question: I'd like to work on a text-based application and
> > > I'd like to act on simply pressing eg. Ctrl (change some context menu).
> > > I can do this with the hack I just posted nicely, but it will fail when
> > > running under X11. Is there any possibility in getting a callback
> > > registered called everytime an event occures which affects my terminal
> > > emulation's window?
> > 
> > No, there isn't.
> > 
> > An application which uses terminal I/O is inherently limited by the
> > set of actions for which the terminal actually generates input.
> 
> Think different. Think of linking mentioned application against
> xlibs/gtk+/whatever.

Then you're talking about an X/GTK+/whatever application. In which
case, you may as well use X/GTK+/whatever for all user I/O.

> Then, if(getenv("DISPLAY")) you could init the X11
> client side. This way, you can work on console (using so far Linux'isms)
> _and_ you can work under X11 within _one_ binary.

This is basically what Emacs does. But the two interfaces are
separate; while you can have both X frames and tty frames within the
same process, X frames receive input as X events, and tty frames
receive input as character sequences.

The down side is that, unless you link statically against the X/GTK+
libraries, you can't even run the application on a terminal unless the
system has the necessary X/GTK+ shared libraries installed.

> What now is the point
> is to fetch all the events which are ment to out xterm's window.

These events "belong" to xterm. While X allows an application to
select events for windows which it didn't create itself, there are
some problems here. E.g., only one client may select
Button{Press,Release} events at any given time, and xterm already
selects these itself.

> So, if you're running on console (!getenv("DISPLAY")), you initialize
> your input routine using ioctl(), but if running under X11, you
> initialize needed xlibs. The remaining problems then is to fetch the
> right events. I currently see no easy way in doing this, but there of
> course must be some:-}

Note that, even if you're running in an xterm, and $DISPLAY is set,
the value of $DISPLAY isn't necessarily the display on which the xterm
is running. The program may not even be able to access the display on
which the xterm is running.

The core problem is that what you are trying to do cannot, in general,
be done with a terminal. There may be specific types of terminal where
it's possible to implement specific solutions (e.g. ioctl(KDSKBMODE)
for the Linux console, X11 API calls for xterm, etc), but there isn't
any solution which will work in general.

The main advantage of "terminal" programs is their portability. They
run on anything which appears as a terminal, e.g. a hardware terminal
(vt100 etc) connected to a serial port (either directly or via a
modem), a terminal emulator (e.g. HyperTerminal) connected to a serial
port (either directly or via a modem), in an xterm, on a Linux
console, via telnet/rsh/ssh/etc.

Personally, I don't consider features which are specific to one
particular environment to be of much use. If you have access to a VT,
you have physical access, so you may as well run an X server and use
the X API. If you can run an xterm, you are already running an X
server, and so may as well use the X API.

Terminal programs are most useful when your only connection with the
system is a single byte stream (modem link, serial cable, TCP
connection etc). In which case, your input is limited to the sequences
which travel across that link.

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

Re: About combined console/X11 programs (was: question about gcc and keyboard hadling)

[+Rudymartin]

and I only asked how to trap the Meta/Ctrl/Shift keys under a terminal LOL

now I have another question: lets say I want to develop the text editor under 
X (and I dont care about portability) which libraries should I use ? (what do 
you recomend for a text editor?) and where I can find the APIs docs ?

Theres a lots of text editors, but I would like to do a Brief emulation 
thats why I need to use the meta and control keys.

thanks a lot. 

Rudy.


On Tuesday 06 August 2002 07:07 pm, Glynn Clements wrote:
> Jan-Benedict Glaw wrote:
> > > > Even better question: I'd like to work on a text-based application
> > > > and I'd like to act on simply pressing eg. Ctrl (change some context
> > > > menu). I can do this with the hack I just posted nicely, but it will
> > > > fail when running under X11. Is there any possibility in getting a
> > > > callback registered called everytime an event occures which affects
> > > > my terminal emulation's window?
> > >
> > > No, there isn't.
> > >
> > > An application which uses terminal I/O is inherently limited by the
> > > set of actions for which the terminal actually generates input.
> >
> > Think different. Think of linking mentioned application against
> > xlibs/gtk+/whatever.
>
> Then you're talking about an X/GTK+/whatever application. In which
> case, you may as well use X/GTK+/whatever for all user I/O.
>
> > Then, if(getenv("DISPLAY")) you could init the X11
> > client side. This way, you can work on console (using so far Linux'isms)
> > _and_ you can work under X11 within _one_ binary.
>
> This is basically what Emacs does. But the two interfaces are
> separate; while you can have both X frames and tty frames within the
> same process, X frames receive input as X events, and tty frames
> receive input as character sequences.
>
> The down side is that, unless you link statically against the X/GTK+
> libraries, you can't even run the application on a terminal unless the
> system has the necessary X/GTK+ shared libraries installed.
>
> > What now is the point
> > is to fetch all the events which are ment to out xterm's window.
>
> These events "belong" to xterm. While X allows an application to
> select events for windows which it didn't create itself, there are
> some problems here. E.g., only one client may select
> Button{Press,Release} events at any given time, and xterm already
> selects these itself.
>
> > So, if you're running on console (!getenv("DISPLAY")), you initialize
> > your input routine using ioctl(), but if running under X11, you
> > initialize needed xlibs. The remaining problems then is to fetch the
> > right events. I currently see no easy way in doing this, but there of
> > course must be some:-}
>
> Note that, even if you're running in an xterm, and $DISPLAY is set,
> the value of $DISPLAY isn't necessarily the display on which the xterm
> is running. The program may not even be able to access the display on
> which the xterm is running.
>
> The core problem is that what you are trying to do cannot, in general,
> be done with a terminal. There may be specific types of terminal where
> it's possible to implement specific solutions (e.g. ioctl(KDSKBMODE)
> for the Linux console, X11 API calls for xterm, etc), but there isn't
> any solution which will work in general.
>
> The main advantage of "terminal" programs is their portability. They
> run on anything which appears as a terminal, e.g. a hardware terminal
> (vt100 etc) connected to a serial port (either directly or via a
> modem), a terminal emulator (e.g. HyperTerminal) connected to a serial
> port (either directly or via a modem), in an xterm, on a Linux
> console, via telnet/rsh/ssh/etc.
>
> Personally, I don't consider features which are specific to one
> particular environment to be of much use. If you have access to a VT,
> you have physical access, so you may as well run an X server and use
> the X API. If you can run an xterm, you are already running an X
> server, and so may as well use the X API.
>
> Terminal programs are most useful when your only connection with the
> system is a single byte stream (modem link, serial cable, TCP
> connection etc). In which case, your input is limited to the sequences
> which travel across that link.

Re: About combined console/X11 programs (was: question about gcc and keyboard hadling)

[Glynn Clements]

+Rudymartin wrote:

> and I only asked how to trap the Meta/Ctrl/Shift keys under a terminal LOL
> 
> now I have another question: lets say I want to develop the text editor under 
> X (and I dont care about portability) which libraries should I use ? (what do 
> you recomend for a text editor?) and where I can find the APIs docs ?

There are many GUI toolkits available for X. I'm not going to get
involved in their relative merits, as such discussions often
degenerate into my-toolkit-is-better-than-your-toolkit flame wars.

> Theres a lots of text editors, but I would like to do a Brief emulation 

Note that there's already a Brief clone, called Crisp.

> thats why I need to use the meta and control keys.

GUI toolkits don't normally report events for pressing and releasing
modifier keys (Ctrl, Shift, Meta etc). Instead, the modifiers are
normally reported as flags with each key or button event.

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

Re: About combined console/X11 programs

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]

On Wed, 2002-08-07 13:00:16 +0100, Glynn Clements <glynn.clements@virgin.net>
wrote in message <15697.3024.599591.170344@cerise.nosuchdomain.co.uk>:
> +Rudymartin wrote:

> > thats why I need to use the meta and control keys.
> 
> GUI toolkits don't normally report events for pressing and releasing
> modifier keys (Ctrl, Shift, Meta etc). Instead, the modifiers are
> normally reported as flags with each key or button event.

I won't go into those my-one-is-bigger-than-... wars, but using GTK+, I
can easily fetch single keypresses/keyreleases. Look at this snipplet:

static gint
keyboard_event_handler(GtkWidget *widget, GdkEventKey *event, gpointer data)
{
	switch(event->type) {
		case GDK_KEY_PRESS:
			printf("Press:   0x%04x\n", event->keyval);
			break;
		case GDK_KEY_RELEASE:
			printf("Release: 0x%04x\n", event->keyval);
			break;
		default:
			/* Make compiler happy at using enums */;
			break;
	}

	return TRUE;
}

window_main  = gtk_window_new(GTK_WINDOW_TOPLEVEL);
...
gtk_signal_connect(GTK_OBJECT(window_main),
	"key_press_event",
	GTK_SIGNAL_FUNC(keyboard_event_handler),
	NULL);
gtk_signal_connect(GTK_OBJECT(pl_window_main),
	"key_release_event",
	GTK_SIGNAL_FUNC(keyboard_event_handler),
	NULL);
...

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: About combined console/X11 programs

[Glynn Clements]

Jan-Benedict Glaw wrote:

> > > thats why I need to use the meta and control keys.
> > 
> > GUI toolkits don't normally report events for pressing and releasing
> > modifier keys (Ctrl, Shift, Meta etc). Instead, the modifiers are
> > normally reported as flags with each key or button event.
> 
> I won't go into those my-one-is-bigger-than-... wars, but using GTK+, I
> can easily fetch single keypresses/keyreleases. Look at this snipplet:

[snip]

But you don't necessarily want to process raw key press/release
events, even if you can.

E.g. for text input, you normally want to process whole characters,
which might require multiple key presses (e.g. using dead keys or
compose sequences).

Similarly, if you are binding commands to Ctrl-<key> and/or Meta-<key>
chords, you don't normally care about events corresponding to the Ctrl
or Meta key being pressed. Instead, you handle the event for the
non-modifier key according to which modifiers are active at the time.

Most of the time, you want to let the toolkit handle the actual event
dispatch. E.g. <key> and Shift-<key> typically go to the widget which
has the input focus, while Meta-<key> goes to the menu bar; Ctrl-<key>
might be a command shortcut which is handled at the top level, or
(e.g. in the case of a text widget) it might be handled by the widget
with the input focus.

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