wayne@csri.toronto.edu (Wayne Hayes) (10/14/90)
A friend of mine is a terminal program guru. He tells me that the ANSI terminal standard, which is a superset of full VT100, supports just about everything you might want to have in tomorrow's terminals -- graphics, fonts, bold, underline, italics, font sizes, colour, windows, 3-D scrolling regions (the third dimension being overlapping windows), etc. In other words, it should be possible, in the future, to write a desktop publishing program on a Unix box that uses ANSI terminal codes to drive a terminal over your 56 Kbaud modem over your phone. Or a really fancy word processor. Or a paint program. Or a just plain really neat terminal program. All driven over a terminal. To me, this looks like an ideal direction for Minix to go. It's a superset of VT100, which is basically what Minix uses for it's terminal output. This means we can add things incrementally, which is the best way for a user-supported system like Minix to grow. At first it won't require any more than what we already have in terminal drivers except in graphics mode -- ie, it will look the same as the current Minix console to the user, except a little slower because it's really in graphics mode. _Then_, we can start to add all the nifty things that the ANSI standard requires. With this, we could even have Minix-to-Minix machine programs that do all this nifty stuff over the serial line! The next step would probably be to add simple windowing so we just have, again, the same text except in multiple windows. And of course mouse support would go hand-in-hand with this. Then cutting, pasting, etc, then multiple fonts -- geez, this sounds like an incredible path! Does anyone have any input, ideas, or counter-arguments? Who says Minix has to support what's already out there? -- "Dad, what should I be when I grow up?" "Honest." -- Robert M. Pirsig, _Zen and the Art of Motorcycle Maintenence_. Wayne Hayes INTERNET: wayne@csri.utoronto.ca CompuServe: 72401,3525
hyc@math.lsa.umich.edu (Howard Chu) (10/14/90)
In article <1990Oct13.140618.3982@jarvis.csri.toronto.edu> wayne@csri.toronto.edu (Wayne Hayes) writes: >To me, this looks like an ideal direction for Minix to go. It's a superset >of VT100, which is basically what Minix uses for it's terminal output. >This means we can add things incrementally, which is the best way for a >user-supported system like Minix to grow. At first it won't require any >more than what we already have in terminal drivers except in graphics >mode -- ie, it will look the same as the current Minix console to the >user, except a little slower because it's really in graphics mode. >_Then_, we can start to add all the nifty things that the ANSI standard >requires. With this, we could even have Minix-to-Minix machine programs >that do all this nifty stuff over the serial line! > >The next step would probably be to add simple windowing so we just have, >again, the same text except in multiple windows. And of course mouse >support would go hand-in-hand with this. Then cutting, pasting, etc, >then multiple fonts -- geez, this sounds like an incredible path! > >Does anyone have any input, ideas, or counter-arguments? Who says Minix >has to support what's already out there? When you've got something that works well, there's no reason to throw it out, right? (This is *not* the same as "if it ain't broke don't mess with it." That is too often an excuse for leaving ugly kludges in place.) I would continue to endorse Bellcore's MGR window manager. (Which was recently ported to the Atari ST.) The client/application library is a mere 40K of object files (smaller, with symbols stripped, natch). It only requires the stdio and signal routines to function. The ST version of the window manager is 200K. Still a bit large for 8086s, but manageable for just about every other Minix version. I think this is the best system around. The control protocol is very like VT100/Tektronix control sequences. There are the usual vt100 style cursor controls, scroll region control, etc. There are also graphics primitves for drawing lines, arcs, circles, and ellipses. By setting coordinate modes from absolute to relative, you get automatic scaling/stretching of drawings when windows are reshaped. (The distribution comes with a clock demo that I like to demonstrate this with. Pull the window about in various ways, and see the hands and clock face stretch to match. Fun...) (But wait - there's more! }-) Lest you think this is merely a trumped up vt100/tektronix emulator... Client programs can tell the server to load fonts, icons, and other bitmaps for use. Any client can use up to 15 fonts simultaneously. Bitmap data can also be sent to and from the mgr server and client, but the preferred mode of interaction is for the client to ask the server to load a file from the server's filesystem. Clients can also download menus to the server, which are invoked as pop-ups, with layering of menus through both sliding off the side and by paging up and down. This system is very flexible, and very powerful, and all it needs to work is a 7-bit data path between the client and the server. (8 bit is necessary if you want to download or upload bitmaps.) Lessee... You also mentioned mouse support and cutting/pasting. Yes, mgr has a system function for cutting and pasting text between windows. Events may be triggered by mouse-button presses, window moves, activations, etc.... The system also includes a bitblit library for manipulating bitmaps and such. Probably the only thing this system doesn't have, that you might want, is arbitrarily shaped windows. MGR windows are rectangles, only. As an example of how powerful this system is, I wrote up a remote window manager for it. (You were asking for Minix-to-Minix windowing?) I am running MGR on my ST, and using a dumb-terminal program to talk to a vax at work. I'm running the remote manager (which I just finished writing/debugging) there and have 3 remote sessions running in their own windows, concurrently. (I took Oliver Lauerman's screen program and gutted it, then threw in window/event/ menu support. It also supports the detach feature that screen has, which lets you disassociate the session from the terminal, and resume the session at a later time, possibly from a different device/location. It just saved me a second ago, in fact, because my modem dropped carrier, but I was able to dial back up and pick up right where I left off, with all windows intact.) Anyway..... MGR makes it easy to write programs that use lots and lots of windows, as I have just proved to myself. I think this is the best choice in windowing systems, and now you sorta know why. -- -- Howard Chu @ University of Michigan one million data bits stored on a chip, one million bits per chip if one of those data bits happens to flip, one million data bits stored on the chip...