Concerning MUI, PUI and GLUI.

By Steve Baker

Introduction

I'm not writing this because the history of MUI is important, I'm doing it because people keep asking me MUI support questions - the answer to all of which is "Don't Use MUI!".

Ancient History

Tom Davis originally wrote MUI (I believe) to support the SGI dogfight game. I find that hard to believe given the structure of MUI - but several people at SGI have told me it's true. MUI was later ported to OpenGL and then to GLUT and released as a part of the GLUT distribution without any documentation whatsoever.

At some point, I was working on one of my (hobby) interests which was to do with writing simple PORTABLE 3D games. I needed a GUI that would be portable - and which would work with OpenGL.

MUI seemed at first glance to be suited to my needs since it renders all its GUI elements in OpenGL and uses GLUT for keyboard and mouse inputs. Since both OpenGL and GLUT are highly portable, so is MUI.

OK, but there was zero documentation for MUI. Zilch, nada.

All you got was a single demo program and the source code. So, I dived in and read the demo - and waded through all the sources figuring out what each API-level function did. I thought I'd do a service to mankind and publish my findings - and that document is this one: http://reality.sgi.com/mjk_asd/tips/mui/mui.html and to the best of my knowledge, it's the only documentation of any kind in existance for MUI.

Now, during the course of writing the document, I realised that MUI has a couple of really nasty problems:

It uses the GLUT pop-up menu to do the drop-down menus on its menu bar. That should be OK - but GLUT implements it's popup menus using the underlying windowing system and not OpenGL. This is very ugly for two reasons:
- You don't have any control over the look-and-feel of the GLUT menu.
- I had just gotten hold of a 3Dfx board for my Linux box. The Voodoo-1 and Voodoo-2 cards are full-screen-only devices - which means that any imagery generated by the underlying operating system cannot be seen. Hence, GLUT popup menus don't appear and MUI applications have menu bars - but they don't seem to drop down when you click on them.
MUI completely takes over all of the OpenGL rendering because it grabs hold of all the important GLUT callbacks. There is therefore no mechanism to allow a background animation to run other than when a mouse button is clicked or something.

So, my entire documentation and discovery exercise was for nothing since I wanted a library that would let me stick a couple of buttons and a menu bar onto my game - and MUI is far too intrusive for that - also I needed to support 3Dfx.

I toyed with the idea of modifying MUI to do what I wanted - but the code is very old and Tom Davis still retains copyright (it's not GPL'ed or anything).

So, I took a deep breath and decided to rewrite MUI from scratch, keeping essentially the same API. But partway through that exercise, I realised that I could do MUCH better with modern object-oriented techniques.

I wrote 'PUI' (named the 'Picoscopic User Interface' because I initially expected it to be smaller and simpler even than the 'Microscopic User Interface' - MUI)

The Alternatives to MUI.

PUI is now widely used - I have over 100 users who have emailed me to tell me that they like it and have used it in real applications. Who knows how many others downloaded a copy and didn't bother to tell me?

You can get PUI here - it's a part of my PLIB (Portable Library) collection: http://plib.sourceforge.net/pui

Meanwhile, I get occasional email from people who still use MUI. Some have found some pretty significant bugs - but I don't really have much to tell those people since I didn't write MUI, and have not even written a single program using it!!

I used to tell them to talk to Tom Davis - but aparrently he stopped using MUI long before it was released with GLUT. Eventually Tom left SGI and I have lost touch with him. The person who controls the GLUT distribution (Mark Kilgard) once offered to distribute PUI instead of or as well as MUI - but now he too has left SGI.

So, MUI is an orphan. It's author will never touch it again. You can't modify and redistribute the sources since Tom still owns the copyright and it ISN'T open-sourced. It has serious bugs in it which will probably never be fixed. The only documentation was written by someone who thinks it's now obsolete and who has never written a line of code using it.

This is not a pretty picture!

I rather wish it would just die - but my document is on the web in Mark Kilgard's old SGI account where nobody will remove it.

PUI is vibrant and fresh - it's GPL'ed so it'll always be free. I still support it - but I havn't had to fix a bug for over 18 months, so it's pretty stable. I get occasional new contributions to it, some I add, some seem just to add unnecessary complexity. The documentation is complete and up to date - and I write new PUI programs frequently.

Also, there is another great package out there with the exact same goals as MUI: It's called 'GLUI': http://www.cs.unc.edu/~rademach/glui/

GLUI is very nice - it's look and feel is closer to X-windows than PUI is - but it's less customisable and less suited to the kinds of interactive applications I wanted to write.

GLUI works better in multi-window user interfaces - where PUI was really designed for simpler stuff.

PUI let's you really customize the GUI so you can have things like translucent menus - GLUI takes more control from you - but then GLUI does things more automatically than PUI does.

Hence, PUI and GLUI complement each other - I write programs in GLUI when it seems more appropriate than PUI. So the two libraries don't really compete and I have no hesitation in recommending GLUI over PUI if that's the kind of thing you need.

If you need a GUI - but you DONT need it rendered in OpenGL - then the field is WIDE open. Look at GTK, FLTK, TCL/TK, Motif, LessTif etc.