| # PUI: A Picoscopic User Interface # Frequently Asked Questions List. By Steve Baker

Here are some questions that have been asked about PUI:

- Q1: Can I build a Windoze DLL for PUI?
- Q2: Which versions of OpenGL and GLUT will support PUI?
- Q3: Which machines/operating systems can run PUI?
- Q4: Is PUI stable? Are there known bugs?
- Q5: What changes do you expect to make in future releases?
- Q6: Where can I ask questions?
- Q7: What's the difference between PUI and MUI?
- Q8: Are there restrictions on using PUI?
- Q9: Do I have to write in C++ to use PUI?

## Q1: Can I build a Windoze DLL for PUI?

Not from the present sources. Some Windoze compilers require an '_export' directive on functions or classes that are to be exported from the DLL. This is ugly and I refuse to add non-standard syntax to the library just to pander to a disgusting Windoze-ism. PUI is a VERY small library and there is really no need for it to be a DLL anyway.

## Q2: Which versions of OpenGL and GLUT will support PUI?

In principal, any version of GLUT since 2.0 and any reasonably compliant OpenGL (including Mesa) should be happy to support PUI.

## Q3: Which machines/operating systems can run PUI?

AFAIK, any machine with C++, OpenGL (or Mesa) and GLUT will run PUI programs without problems.

## Q4: Is PUI stable? Are there known bugs?

So far, there have only been a couple of bugs reported in PUI - the most significant is that the menu bar doesn't work properly after the GLUT window has been resized.

The 'complex' demo program seems to fail when a dialog box is dismissed. This may be because the dialog object is deleted inside a callback within a member function of that object. This problem only appears under Microsoft operating systems and so is hard for me to track down. The simplest thing may be for me to change the demo program so it just doesn't work that way.

## Q5: What changes do you expect to make in future releases?

I am generally unhappy about the somewhat inconsistant set of constructor functions for the various widgets. Some auto-size their widgets, some take the size directly, others have both. This needs to be made much more consistant across all the widget classes.

I want to write a cute interactive GUI designer program to write C++ source code for the PUI constructor functions automatically. Something along the lines of the XForms 'fdesign' or the FLTK 'fluid' programs.

If GLUT ever changes to allow applications to run without calling 'glutMainLoop', I will greatly improve the Dialog box API which sucks right now. It would also spur me on to write a File Selector widget. The problem is that you'd really like to be able to write things like:

        if ( ( fd = fopen ( "babble", "w" ) ) == NULL )
        {
          if ( puYesNoDialog ( "Can't open babble file",
                               "Do you want to continue?" ) )
            return ;
          else
            exit ( 1 ) ;
        }

However, the 'puYesNoDialog' function can't get it's graphics up on the screen without returning to GLUT's main loop - and it can't do that since the call to puYesNoDialog is in a GLUT callback function. Look at the ugly code in 'complex' to see how to do this kind of thing without this facility.

Finally, the appearance of PUI's widgets is somehow not as neat as some other GUI's such as MUI and Motif. This should be pretty easy to fix - and it's something on the 'to do' list.

## Q6: Where can I ask questions?

Since PUI is now a part of PLIB, all user level questions, development issues and announcements are handled from the PLIB mailing list.

## Q7: What's the difference between PUI and MUI?

The main reason I wrote PUI was my disappointment with MUI.

MUI has now been 'abandoned' by it's author (Tom Davis) who none-the-less retains copyright over it. MUI has several known bugs - and the only known documentation was written by me - and I have never actually written a real application using it!

The MUI library (distributed with GLUT) takes over all of the GLUT callbacks - this makes it very hard to write general purpose programs with MUI.

In contrast, it is very easy to add PUI widgets to an existing OpenGL/GLUT application with only a couple of lines of code.

PUI also works quite well with 3D hardware such as 3Dfx Voodoo that 'take over' the screen. Since MUI and GLUT both create their menu's using the underlying windowing system's GUI, these menu's won't be visible on that kind of hardware. PUI uses only OpenGL to do all kinds of widgets, so portability onto 3Dfx hardware is assured.

## Q8: Are there restrictions on using PUI ?

PUI is OpenSource under the terms of LGPL. If for some reason, you find LGPL too restrictive and if you wish to use it in some major project then please talk to me about it - I can be flexible.

## Q9: Do I have to write in C++ to use PUI?

Yes - there will never be a {insert favorite non-C++ language here} version of PUI.