Dimitar Zhekov wrote:
DZ>> Warning: any attempt to read from stdin while in "graphics" mode DZ>> blocks the application. This is a bad practice IMHO ... DZ>> there are any objections, replace such reads with GrKeyRead()-s. FH> I have some programs that do terminal (via ncurses) and GRX I/O at FH> the same time (under X11, in two windows -- xterm and GRX). I don't FH> see a bad practice in this. Normally, GRX runs in fullscreen mode and there is no 2nd window where to perform terminal I/O, so it can't be guaranteed that the terminal I/O will work while in graphics mode, or that the GRX I/O will work while in text mode.
You mean in the non-X11 versions? (In X11, the window is as big as I make it, say 800x600, with space for more windows.) It might be possible under Linux (FreeBSD?) to use two virtual consoles this way (i.e., run the GRX program on one console and redirect its standard I/O to another one or set it up via newterm() in curses). I've never tried this and don't really plan to, though ...
I don't use MS-Windows, so I don't know if it's possible to launch a GRX program from the command line window and let it open a graphics windows and still do text I/O. I think it would be nice if it is possible ...
Moreover, the terminal I/O may try to echo the characters entered on the graphics screen (if fullscreen), or even try to scroll it, thus corrupting the graphics image.
Of course, doing text and graphic I/O on the same screen (not in different windows) is not a good idea, I know.
FH> Would this break with those changes? Only if you (1) set USE_XF86DGA_DRIVER=y in makedefs.grx, (2) activate XFree86 DGA2 (it's off by default) and (3) run your programs as root.
Should be no problem then, since these programs are not meant to be run as root.
Frank