pbrown@volcano.Berkeley.EDU (Philip Brown) (04/10/90)
After playing around with Xwindows for a while, I wanted it for the CoCo,
while I was rlogged in with my modem.But I realized X is Too Big.
"What a shame. It's so nice to be able to flick between windows in
UNIX, just like on my coco with OS9 LII"
Then I realised that all I wanted was the multiple windows. So I started to
look at how X-windows does it. Have you noticed that each window gets its
own tty?
So I started hunting through the manuals online, and a bit of source. then
I realised that the thing that gets things done is the window manager,
uwm, gwm, twm, or whichever. The X system really is not used much. that's
what xterm is for: to run things(jove, cc, ..anything..!) that weren't
meant for X, in an X-window.
Also, while in a session of impromptu core-wars, I found that echoing xxx
>/dev/ttyxx sends something to ANY OTHER PERSONS(or your own) window.
I didn't realise the significance at the time. what this means, however,
is that window managers DON't CARE about processes: they just poll the
tty associated with them!!!
So that should be easy enough. The hard part is how to get the right
window on your coco outputting to the correct process. I presume it's got
to be some special pty function, but I haven't a clue as to what that is.
[note: yes, that WAS _p_ty]
Once I find out, hoowever, it's just a matter of writing a simple terminal
program that, on command, turns OFF it's command filter
(the thing that filters out unneccessary ESCs, and such), and watches out
for special signals.
(This is because, while to define a window, all you have to do is
send 1b 20 x ... etc..., you still have to send it to the right
window, and INIZ it if it isn't !!!)
There you are, for all you UNIX phreaks out there. help me along, and os9
will be better, and MORE PORTABLE than ever !!!
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Philip Brown pbrown@ocf.berkeley.edu
"I'm living on borrowed RAM" - Jon Aldrich
***********************************************marcotte@acsu.Buffalo.EDU (brian r marcotte) (04/10/90)
In article <1990Apr10.003925.10348@agate.berkeley.edu> pbrown@volcano.Berkeley.EDU (Philip Brown) writes: > Also, while in a session of impromptu core-wars, I found that echoing xxx >>/dev/ttyxx sends something to ANY OTHER PERSONS(or your own) window. >I didn't realise the significance at the time. what this means, however, >is that window managers DON't CARE about processes: they just poll the >tty associated with them!!! Think thats funny? Try setting your DISPLAY environment variable to someone elses X-Terminal or SUN and running an X application. - Brian Marcotte
darrenr@munnari.oz.au (Darren) (04/10/90)
In article <21405@eerie.acsu.Buffalo.EDU> marcotte@acsu.Buffalo.EDU (brian r marcotte) writes: >> Also, while in a session of impromptu core-wars, I found that echoing xxx >>>/dev/ttyxx sends something to ANY OTHER PERSONS(or your own) window. >>I didn't realise the significance at the time. what this means, however, >>is that window managers DON't CARE about processes: they just poll the >>tty associated with them!!! >Think thats funny? Try setting your DISPLAY environment variable to >someone elses X-Terminal or SUN and running an X application. here at melb uni, we have a net of suns and you can login from one to another. Some things, esp. games, don't bother to check that the console of the sun you are on is actually yours. With this you can run a program and write all over their console (very bad manners and VERY annoying.). darren
pete@wlbr.IMSD.CONTEL.COM (Pete Lyall) (04/11/90)
In article <21405@eerie.acsu.Buffalo.EDU- marcotte@acsu.Buffalo.EDU (brian r marcotte) writes: -In article <1990Apr10.003925.10348@agate.berkeley.edu> pbrown@volcano.Berkeley.EDU (Philip Brown) writes: - -> ...they just poll the tty associated with them!!! - -Think thats funny? Try setting your DISPLAY environment variable to -someone elses X-Terminal or SUN and running an X application. - - - Brian Marcotte Not fully accurate. In order to access the remote server, that server's owner must have granted you access, via 'xhost +', or similar mechanism. It's not all out in the open, as implied..... Pete -- Pete Lyall Contel Corporation Compuserve: 76703,4230 OS9_Net: (805) 375-1401 (24hr 300/1200/2400) Internet: pete@wlbr.imsd.contel.com UUCP: {hacgate,jplgodo,voder}!wlbr!pete
lapp@hppad.HP.COM (David Lapp) (04/11/90)
> Then I realised that all I wanted was the multiple windows. So I started to So what you are looking for is a means of having multiple sessions going with a Unix system over a serial line correct? > look at how X-windows does it. Have you noticed that each window gets its > own tty? Well not quite. I believe that only each Xterm (or whatever terminal emulator you are using) gets its own pty. Other processes (such as Xclock) don't need a pty. > So I started hunting through the manuals online, and a bit of source. then > I realised that the thing that gets things done is the window manager, > uwm, gwm, twm, or whichever. The X system really is not used much. that's > what xterm is for: to run things(jove, cc, ..anything..!) that weren't > meant for X, in an X-window. Depends on what you mean by 'getting things done'. The window manager does certainly do some things but... it may not be as omnipotent as you might think :-). Keep in mind that you can run xterm (or any other X client) without benefit of any window manager. (You just have to do it from some other tty! (As some others have pointed out!!)) Xterm does provide the means of running X 'dumb' programs on an X server. Thats why it uses pty's. That fools those X 'dumb' applications into believing that they are talking to a serial port. Telnet does the same thing. > is that window managers DON't CARE about processes: they just poll the > tty associated with them!!! No window managers don't poll tty's. The application (ie. the shell in an interactive session) talks to the slave side of the pty. Xterm sits on the master side of the pty and talks to the X server. Anything that the window manager finds out about the other clients comes from the X server. Hope that this helps Dave Lapp Standard Disclaimer etc...
marcotte@acsu.Buffalo.EDU (brian r marcotte) (04/11/90)
In article <51416@wlbr.IMSD.CONTEL.COM> pete@wlbr.imsd.contel.com.UUCP (Pete Lyall) writes: >-Think thats funny? Try setting your DISPLAY environment variable to >-someone elses X-Terminal or SUN and running an X application. >- >- - Brian Marcotte > >Not fully accurate. In order to access the remote server, that >server's owner must have granted you access, via 'xhost +', or similar >mechanism. It's not all out in the open, as implied..... > >Pete Well, it must work differently at other places, but here (SUNY Buffalo) I know that all you have to do is set the DISPLAY to another X-Terminal or SUN, and your applications will appear over their. Example: If someone wanted to be funny, they could change your background to something rather offensive. - Brian Marcotte
bush@acsu.Buffalo.EDU (christophe e bush) (04/11/90)
In article <21550@eerie.acsu.Buffalo.EDU> marcotte@acsu.Buffalo.EDU (brian r marcotte) writes: >In article <51416@wlbr.IMSD.CONTEL.COM> pete@wlbr.imsd.contel.com.UUCP (Pete Lyall) writes: > >>-Think thats funny? Try setting your DISPLAY environment variable to >>-someone elses X-Terminal or SUN and running an X application. >>- >>- - Brian Marcotte >> >>Not fully accurate. In order to access the remote server, that >>server's owner must have granted you access, via 'xhost +', or similar >>mechanism. It's not all out in the open, as implied..... >> >>Pete > >Well, it must work differently at other places, but here (SUNY >Buffalo) I know that all you have to do is set the DISPLAY to another >X-Terminal or SUN, and your applications will appear over their. >Example: If someone wanted to be funny, they could change your >background to something rather offensive. > > - Brian Marcotte > No, it doesn't work differently here. The thing is that if you set your environment variable to an X-Terminal or Sun Workstation and then run an X client from one of the time-sharing machines (i.e. autarch or lictor, sorry non UB netters, those names won't mean much), most users of X around the University have granted those hosts the right to display on their machines. Since the NCD terminals aren't self contained computers, they must allow access to the time-sharing hosts because these hosts serve these terminals. Therefore, if you are on an X terminal (or any terminal from which you can log into one of the time-sharing hosts), you can set your environment variable to one of the X terminals and run a client to display on that screen. This includes from a Sun to one of those. However, if you are on a Sun, you may elect to only allow clients running locally on your workstation to display on your workstation. Most users again however have allowed access to their displays from the time-sharing hosts because clients run on those hosts are typically faster. If such a person were logged into a Sun, say Twain in the Graphics lab, and only allowed access from twain`s cpu (via 'xhost twain', and you did the following from your terminal: >setenv DISPLAY twain.cc.buffalo.edu:0.0 >xloadimage -quiet -onroot some_image you would get an error message that said you could not open that display. Some users initialize X on startup and have a command like 'xhost ...' with a list of allowed hosts after the xhost command. Alternatively, they may have simply used 'xhost +' which allows access to their display from all known hosts (not necessarily a good thing). Anyway, this obviously doesn't belong in an os9 group, but just wanted to clear things up. Besides, it may help someone in emulating an X type windowing environment on their ST or other os9'er. - Chris Bush (UCS Graphics Consultant)