question about gcc and keyboard hadling
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.
Quoted 6 lines · +Rudymartin
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>.
Signature · 1 line
Glynn Clements <[email protected]>
On Mon, 2002-08-05 15:43:18 +0100, Glynn Clements <[email protected]> wrote in message <[email protected]>:
Quoted 10 lines
Quoted 6 lines · +Rudymartin
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.
Quoted 2 lines
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] = 1tcsetattr(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
Signature · 3 lines
Jan-Benedict Glaw . [email protected] . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/
On Mon, 2002-08-05 15:43:18 +0100, Glynn Clements <[email protected]> wrote in message <[email protected]>:
Quoted 10 lines
Quoted 6 lines · +Rudymartin
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
Signature · 3 lines
Jan-Benedict Glaw . [email protected] . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/
Quoted 6 lines · Jan-Benedict Glaw
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.
Signature · 1 line
Glynn Clements <[email protected]>
About combined console/X11 programs (was: question about gcc and keyboard hadling)
On Tue, 2002-08-06 17:22:57 +0100, Glynn Clements <[email protected]> wrote in message <[email protected]>:
Quoted 10 lines
Quoted 6 lines · Jan-Benedict Glaw
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?
Quoted 4 lines
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
Signature · 3 lines
Jan-Benedict Glaw . [email protected] . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/
Re: About combined console/X11 programs (was: question about gcc and keyboard hadling)
Quoted 7 lines · Jan-Benedict Glaw
Quoted 7 lines
Quoted 6 lines
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?
Quoted 7 lines
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 5 lines
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.
Signature · 1 line
Glynn Clements <[email protected]>
Re: About combined console/X11 programs (was: question about gcc and keyboard hadling)
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.
Quoted 75 lines · Glynn Clements
Quoted 7 lines · Jan-Benedict Glaw
Quoted 7 lines
Quoted 6 lines
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?
Quoted 7 lines
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 5 lines
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)
Quoted 5 lines · +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 ?
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.
Quoted 1 line
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.
Quoted 1 line
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.
Signature · 1 line
Glynn Clements <[email protected]>
Re: About combined console/X11 programs
On Wed, 2002-08-07 13:00:16 +0100, Glynn Clements <[email protected]> wrote in message <[email protected]>:
Quoted 7 lines
Quoted 1 line · +Rudymartin
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 gintkeyboard_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
Signature · 3 lines
Jan-Benedict Glaw . [email protected] . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/
Re: About combined console/X11 programs
Quoted 8 lines · Jan-Benedict Glaw
Quoted 5 lines
Quoted 1 line
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.
Signature · 1 line
Glynn Clements <[email protected]>