Date: Sun, 08 Apr 2012 21:45:57 +0200 From: Michael Cardell Widerkrantz <mc@hack.org> To: freebsd-hackers@freebsd.org Subject: Re: Graphical Terminal Environment Message-ID: <86ipha2eiy.fsf@totoro.hack.org> References: <CAGSJxJ7yRZJydw7fNGyTnsykfsJf2Q0VzoFbKX-%2BSgNspiOhoA@mail.gmail.com> <4F55A0EA.8000300@gmail.com> <CAGSJxJ5BBPkrjwGFLomFvoj%2Bh_qaEmqT%2Bi6tVx__tBVf4yZDYg@mail.gmail.com> <CA%2BtpaK3Fp8m%2B0ccAjiAAKj_JJ1nQEYRBSwg_sYEPqOoWJgUfog@mail.gmail.com> <CAGSJxJ7i-fiNQieACQcKVd%2BvrKvL7eMiwHBq60rUKB=8i5vQiQ@mail.gmail.com> <4f5635d4.5Qp6ViEgiFLUuPKI%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Since Brandon started this in a sort of rambling mood I'm keeping up with the tradition... This is just what's on top of my mind right now. perryh@pluto.rain.com, 2012-03-06 17:05 (+0100): > I _think_ SunTools/SunView were proprietary, Absolutely. > although it's possible that Sun released the source code at some > point. Much of the actual window system in SunView was implemented in the kernel, IIRC. That might not be interesting in this case. Another system I used on quite memory-starved Sun 3/50s (as little as 4 meg) and 3/60s and later on SPARCstations, was the Bellcore MGR window system: http://hack.org/mc/mgr/ http://en.wikipedia.org/wiki/ManaGeR Many users in the Lysator academic computing society where I first met MGR preferred it to SunView. It was really nice on monochrome monitors at 1152x900. It's also network transparent so you can run remote graphics applications. MGR was ported to a lot of systems, including FreeBSD. It might still compile, but it's unlikely to support anything higher than 640x480 on FreeBSD. If anyone tries to compile it and runs into problems I might be able to help. Just e-mail me. To support higher resolutions on FreeBSD Brandon would have to rewrite the functions in libbitblit. One way to do it would be to use vgl(3) to implement the libbitblit functions. Should be pretty straightforward, I think, and not too much work. On the other hand vgl(3) probably only supports VESA so Brandon will still have to write a special libbitblit for the nvidia card he mentions. MGR doesn't tile windows but Brandon might want to add a mode to do that. MGR has a slightly bothersome license, though, forbidding commercial sales so this might not be the best way forward. On Sun SPARCs under SunOS it was also possible to run a tiling window system called Oberon. It shares its name with a programming language and a complete native operating system. Oberon is a complete environment using the Oberon programming language so it might not be what Brandon wants but it might be interesting to look at nonetheless. I believe Oberon is still available and can run either as a native operating system or as an environment under other systems. The SPARC port I used many years ago was running under SunOS but was running directly on the console. I don't know if there are any modern Oberon systems that can do that. Incidentally, Oberon was one of the inspirations behind Rob Pike's acme editor on Plan 9. Acme, however, just handles text. Oberon does graphics as well. I've been thinking something along the same lines as Brandon for several years now: to write a lightweight window system. For many years I resisted X and kept using MGR, even going so far as porting MGR to Solaris and to Linux/SPARC just to be able to keep using MGR on more modern systems. I gave up, I think, around 1994. If I would do it again I would probably not work on MGR but I might use it for some ideas. One thing that MGR does that I wouldn't do was to force all graphics operations to be done through escape codes in terminal windows. While it might be great for network transparance it's not so great for the speed of local programs. The Wayland project is interesting but seems very Linux oriented. On the other hand work on KMS/GEM support on FreeBSD is coming along. It might be possible to get Wayland running on FreeBSD. I haven't looked into it myself (yet). James Gosling, who wrote both the Andrew window system and Sun's NeWS (not SunView, the *other* Sun window system, the one with a Postscript interpreter) has written an interesting paper about window system design. I have a copy here: http://hack.org/mc/texts/gosling-wsd.pdf Some people have mentioned Plan 9's 8 1/2 and rio. They are both very interesting window systems. While I think they have a very clean design I think they might be problematic to implement in a system other than Plan 9. You see, both 8 1/2 and rio are *file servers*. They make heavy use of the fact that the namespace of files in Plan 9 is local to processes. Reading from /dev/mouse from a process under 8 1/2, for instance, means listening to mouse events in the window that process is running in. Another process has a *completely separate* /dev/mouse file but is using *the same name*. Neat, but not very portable. I've used 8 1/2 many years ago but haven't used rio. I believe the difference between them is fairly small, but I might be wrong: I think rio allows the process to write pixels directly to a window while 8 1/2 uses special commands written to /dev/bitblt. Right? Rob Pike, the author of both 8 1/2 and rio, also wrote several earlier window systems that are interesting, for intance mtx and mux on the Blit and its decendants, the AT&T Teletype 5620 DMD, AT&T 630 and 730. Some software for these terminals/light workstations is still available. See: http://www.brouhaha.com/~eric/retrocomputing/att/5620/ An entertainging video featuring Pike and the Blit is available here: http://www.youtube.com/watch?v=waTL1abCm9I Notice that they really felt the need to explain how a mouse works. Alright, this was 1982. An interesting idea I've been thinking about is making a new window system API at least partially compatible with either MGR's API (not the escape codes - the C functions) or the AT&T terminal's API, or perhaps making a compatibility library. This way a lot of fairly nice very lightweight software like troff previewers et cetera would be available from the start. Is this a waste of time? I don't know. For instance X11 on the grownup smartphone I use right now, an ARM based netbook from Genesi, is nice to have but there's very limited memory on the box and I would rather use the memory for something else. One of my thin clients, an HP t5125 from 2005, has even less memory: 128 MiB soldered on the motherboard. It still makes a quite nice diskless workstation but with a more lightweight window system it would be nicer still. I think there are many such boxen around that might still be useful. Happy hacking, MC -- MC, http://hack.org/mc/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86ipha2eiy.fsf>