[By mc at the domain hack.org. Originally written in 1993?] Newsgroups: gnu.misc.discuss References: Mirai wrote that it is time for a GNU Window System and that we should just say no to Xlib and the X Window System. While I agree that it would be very nice to have a GNU alternative to the X Window System, I think it was decided from the start of the GNU Project that the X Window System would be the window system for the GNU operating system. On the other hand, in the GNU Manifesto, RMS wrote: [There will] perhaps eventually [be] a Lisp-based window system through which several Lisp programs and ordinary Unix programs can share a screen. I like this idea and I have been using gwm, the Generic Window Manager, which is programmable in WOOL, Window Object Oriented Lisp, that does just that, but gwm is rather bloated and slows down everyday operations *a lot*. I know there are other window systems on top of, for instance, GNU Common Lisp, but most of them are built with X11 in mind and doesn't work as replacements. When it comes to the look of the user interface, I am rather found of things minimalistic, and hence I have come to like the look of the Plan 9 8½ window system. 8½ is programmed through the use of special device files that can easily be mounted over a network, thus providing a network transparent window system in a very neat way. It is very easy to program from just about any programming language that has facilities to write to a file. 8½ is, however, rather dependent on the Plan 9 view of the system, where just about everything is treated as a file. I don't think NFS would lend itself to exercises such as this, although perhaps AFS (the Andrew File System) would. Some months ago, however, I suddenly realized that back when I was using Sun 3/50s and 3/60s (MC68020, 68881 FPU, Sun custom MMU, 4 MB and 8 MB RAM respectively) as my main computers, I used a small, minimalistic window system as an alternative to SunView (this was all before OpenWindows and OpenLook) that was delivered with the operating system. This small, easy to program system, was known as the Bellcore MGR window system, which was programmed through the use of a small protocol in the form of terminal codes, sent to any MGR window. The MGR window worked in a way similar to any ordinary graphics terminal, but with a difference: the application talking to the MGR window could tell the window to create a new window on the screen with the same characteristics, download bitmaps, and in general tell the window to let the MGR server perform graphics operations on it. One really neat thing about the system was that you could easily tell the MGR system *what* character strings (yes, *any* character strings) it would bind to certain events. Then, when these strings was sent to the window, the MGR display server would act accordingly. This made it really easy to write GUI wrappers around non-GUI programs. Since the terminal code based window protocol is so small and can be sent through ordinary tools such as telnet, rsh or ssh, MGR is in effect a network transparent window system. What's more, since the window protocol is so small, it is possible to use MGR clients talking to the MGR server from the other side of a slow dial-up line. If you don't feel like using PPP or SLIP and you want to have multiple MGR clients running on the remote side of things, there are allready two MGR clients that can work as multiplexors; Mtx and Rmgr. Try using X11 over PPP on a 14.4 kb/s dial-up line (no Xremote or LBX cheating) some time and you realize why MGR and an MGR mux is a great idea. I looked through the net for references to MGR and found out that it was still around, now ported to the Sun SPARC architecture, DECstations and Linux and FreeBSD on PCs. Earlier distributions, that I allready knew of, was for Sun 3 under SunOS, MiNT on Atari, Macintosh, Coherent and Minix. I also noted that there was a distribution for Andy Valencia's real-time Plan 9 look-alike VSTa operating system, which I have been dying to try for some time. I would like to see MGR ported to NetBSD and Solaris for SPARC and Intel as well, and I think it shouldn't be too hard. Oh yes, since X11 doesn't seem to be ported to the HURD yet, MGR might be the first window system ever running on the true GNU... I snarfed the major distribution and compiled it on my old Sun SPARC ELC and had a go. Whoaaa! Instant hit of nostalgia! If you want to have a look at what my screen looks like on the ELC, point your favourite WWW browser towards http://www.lysator.liu.se/~cardell/mgr/ [MC: The link above is old. See, instead, http://hack.org/~mc/mgr/.] and snarf the screenshot. There doesn't seem to be much development on MGR nowadays, however, and I've been thinking about going through all the new code since my days as an MGR hacker and see if I can pick it up and become the maintainer. Vincent Broman has been working a lot on MGR before, but now he says he's mostly using MGR, not developing it, though still sending out the occasional bug fix. He writes that he is willing to cooperate, however. One very neat thing that was in the new distribution that I didn't know of, was mgr.el, an Emacs Lisp support library for MGR. Through the use of of the functions in mgr.el you can have *complete* control over MGR from within Emacs Lisp programs; open new windows, download bitmaps, check for events, et cetera. This might just be the Lisp-based window system RMS dreamed about... An Emacs-based window system... Now, how does MGR match Mirai's wish list? - a lightweight system that is not bloated Check. The MGR server, with six or seven windows open, not much graphics, an Emacs and a few other things on an 1152x900x1 screen takes up about 300 kB on my ELC under SunOS. The MGR clients are usually very small, too. The entire source distribution is about 7 MB, with a lot of fonts, icons and client programs, including a basic drawing program, DVI and *roff previewers, a useful "movie" feature to catch the interaction with an MGR application and replay it later, et cetera. After installation, the binaries and the fonts, icons, libraries et cetera takes up about 4 MB of disk space. - completely written in c++ Uh... How does this match with the above, about not being bloated? *evil grin* Well, no, MGR is not entirely written in C++. There's one thing or two that is, though. The rest is written in C or as Bourne shell scripts, except of course the Emacs Lisp library. - efficient Efficient in what way? In the use of RAM? CPU? Something else? I don't think the MGR port to SPARC use the graphics accelerator in my ELC, for instance, becuse the XsunMono server seems slightly faster, so MGR is more of burden to the CPU. The vector drawing routines are especially nasty, I'm afraid. However, this is not much of a nuisance doing ordinary work. I realize others may think otherwise about the graphics operations, but I'm not bothered. I usually run Emacs, an analogue clock, a program showing the machine load, mgrbiff (to show me if there's any mail), mgreyes (that constantly keep their eyes on my mouse pointer) and a couple of shell windows. Then, occasionally, I use pgs, using Ghostscript with MGR support, to view PostScript files as generated from dvips and other things. People using their computers for about the same things might enjoy MGR. - can run on machines with only 4M of RAM Check. And possibly with as little as 2 MB, depending, of course, on the underlying system. I imagine the Coherent port can. - slash the number of routines to a reasonable amount Check. There are about 120 C macros expanding into something like ordinary printf()s that make out the lowest level library for MGR programmers. These macros covers all text and font, bitmap, window and menu manipulation as well as client to client messaging facilities. Then there's about 30 higher level functions, combining several of the most often used macros together. - no proprietary development (no X/Open, no X consortium) Um... The copyright license of the MGR distribution is a little special. It says: Copyright (c) 1988 Bellcore All Rights Reserved Permission is granted to copy or use this program, EXCEPT that it may not be sold for profit, the copyright notice must be repro- duced on copies, and credit should be given to Bellcore where it is due. BELLCORE MAKES NO WARRANTY AND ACCEPTS NO LIABILITY FOR THIS PROGRAM. Perhaps re-writing the lower level parts of MGR (which are affected by this statement) could change that or perhaps someone could contact Bellcore and see what they think about changing the copyright statement. Stephen Uhler, the original developer is, alas, not at Bellcore anymore. I think, or so people tell me, that he is currently somewhere at Sun Microsystems. Stephen, if you're reading this, please reply to me. - abolish the client-server paradigm Uh... MGR doesn't do that. Instead, it re-inforces it, but it also makes it possible to have client<->client communication within the window system. What would you like to propose instead if you want to provide a network transparent window system? - export the GUI not the display (a la active X) I don't know anything about Active X, but MGR has a user interface, of a sort, built into it. It has a limitied support for menus, accessed through pressing mouse buttons in the window or the screen background. Thus, no menu bars clutter up valuabe screen space. Given the right specifications, it would probably be easy to add support for other user interface tools. - get rid of rediculously complex color models (eg. CIELAB, CIELUV, etc.) and establish one simple rgb model I don't know much about colour myself, since I tend to use monochrome monitors. I do know that the new distribution of MGR seem to have colour code, unlike the old Sun 3 distribution, when colour was only experimental... I think you can set the colormap using a simple tool, which prints this on my screen when I execute it: frobozz:~: colormap usage for getting/setting colors: colormap col colormap low_col hi_col colormap col r g b [max_inten_if_not_255] frobozz:~: which suggests that it is uses some sort of RGB model. - drawing routines: line, arc, point, and Bezier curvers! Check. See above about vector graphics. - all drawing routines are ANTI-ALIASED Well, no... - Type manager is fast, simple and supports TrueType/PostScript rendering as ANTI-ALIASED text Check for simple, but the type support in MGR is basically just for mono-spaced fonts. You basically load the fonts into the server, indexed through a number. Then you set the current font pointing to that slot and voila! You have changed the current font to new bitmaps. There are some functions that can deal with Hershey fonts, but there's no *real* support for proportional fonts. I think this is important, so that would be one of the main things that had to be changed. - low-level routines are callable as functions and are not client-server based Hm... All the low level routines in the MGR C library are basically macros that expand to printf() statements. - allow easy low-level access to screen and window memory for game or 3d designers Well... You can download bitmaps off screen in a window and then move it into visibility, but I don't think this will do if you want to do 3D design programs or something like that. I guess this will require new functions in the server. I don't like the idea of using special cases for local clients, but that might be necessary if we really want to allow more or less direct access to the screen and window memory. - system should be easily portable to any architecture/OS Check. See above for list of ports. - an easy "high-level" toolkit should run, easy to understand, easy to use, and easy to port in the vein of the Qt toolkit. I don't know the Qt toolkit, but since the MGR low level routines are so easy, and there's allready a limited higher level library, these things should be easy to write. - easy hooks to a scripting language, so that the average user can script a GUI easily (a la tcl/Tk or perl/Tk). Check. Any language that can print things on stdout can control MGR. I've allready tried some things in Perl, Python and my own Forth system, but I haven't added a complete library to any of them. - define a common (default) widget set based on the look and feel of something more like a combo of NeXT and Windows 95 A nice widget set would be nice, but I don't know about Lose 95. There are a lot of icon graphics that are really more usable as buttons and widgets of all kinds in the MGR distribution allready. - define a default look and feel but allow for others There is allready a tradition for how MGR programs should behave, but I think the interface might need some refinements. - make it 10 times easier to program in than X or MS-WINDOWS Check. MGR is much easier to program than X, or at least it is for me. Try writing "hello world" using only Xlib! - make it run faster than X or MS-WINDOWS As I said above, the SPARC port doesn't seem to use any graphics accelarator, so these thing has to be worked upon. But MGR *is* fast on everyday routines such as repositioning windows, moving things et cetera. - make it more efficient and take up less RAM than X or MS-WINDOWS Check. Easy. - make it 10 times easier to learn than X or MS-WINDOWS Do you mean easier for the end user to learn the user interface or easier to learn how to program?