On Wed, 2008-10-22 at 10:54 -0600, andrey mirtchovski wrote: > > This has one or two complications. There is no way to interrupt or kill > > the foreground process. Instead, ctrl-c interrupts 9vx itself. > > chris, > > one of the nice things about the Plan 9 graphics system is that rio is > in no way different than any other graphical program. it reads and > writes files in /dev/wsys and multiplexes them between other > applications. in that sense, you don't need to run rio in order to run > a graphical app. from the 9vx console you can just type 'acme' and > you'll have acme running in full-screen mode. if you know what you > desire in a window manager (perhaps a terminal window in a static > location to which you can always return, or keyboard-driven window > switching) one can be written so that it's used instead of rio. > graphical programs in plan9 are not hard. > > in the mean time you wan use acme's terminal (the program is called > 'win') to gain a more feature-full environment.
Everything up until this point made total sense to me. But now, that you've brought acme into discussion -- I'm confused. Granted, I happen to NOT be an acme user myself so may be that's why I see nothing that it brings to the table in this particular situation. The previous suggestion was around rio which, at face value was more than reasonable especially if one considers rio's desire to stay explicitly out of the way as far as drawing surfaces multiplexing is concerned: From rio(4): "Note that the draw(3) device multiplexes itself; rio places windows but does not mediate programs' access to the display device." It seems that all we need from rio(4) in a tty-only scenario is its ability to multiplex /dev/cons in a way that also interprets particular sequences of bytes (like Ctrl-C, Ctrl-D, and may be even escape sequences) and translates those into actions: sending a note to a process, creating a new window, etc. It almost sounds exactly like what screen(1) is doing for UNIX ttys. It probably will require some changes to the existing code for rio. That's what I would call an internal multiplexing: 9vx is running with its stdin, stdout and stderr attached to a tty and that's what gets served as '#c/cons'. The only process that accesses it is rio. The rest of the Plan 9 processes see /dev/cons served by rio. So far so good, except that 9vx *already* seems to interpret things like Ctrl-D: linux-box$ ./9vx.Linux -g -u glenda init: starting /bin/rc upas/fs: '/bin/upas/fs' does not exist #m/mousectl: rc: can't open: jmk added reentrancy for threads init: rc exit status: rc 5: error init: starting /bin/rc % cat % It looks like when I pressed Ctrl-D that got interpreted as an EOF coming from '#c/cons' right? In that same spirit, interpreting DEL as a character that triggers a note to be sent should also be quite doable within the #c driver. The only question is -- where such a note is supposed to be sent to? Can someone, please, educate me on the moral equivalent of process groups, sessions and their relationships with #c/cons ? Thanks, Roman.
