I think your analysis is right on.  Whether we want the application to be able to change the menu font depends strongly on how much we want to extend "freeglut" beyond GLUT.  And that will wait for Steve Baker to weigh in, although I daresay he will listen to other people's opinions on this.  (This is the cue for the OpenGLUT community to take the ball and run.)

        If I may give a gratuitous advertisement, my own application gets its menus from PUI, which is part of PLIB.  But it doesn't do submenus, although I wish it would.

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
-----Original Message-----
From: [] On Behalf Of Richard Rauch

Sent: Thursday, September 15, 2005 7:03 PM
Subject: Re: [Freeglut-developer] menu font

On Thu, Sep 15, 2005 at 02:50:24PM -0500, Fay John F Contr AAC/WMG wrote:
> Burns,

>     Well, at the moment there isn't a good way to change the menu font
> without recompiling.  Since GLUT used system menus, it didn't have a way to
> change the menu font either.  If you can recompile, line 58 of
> "freeglut_menu.c" is where you need to make the change to use a different
> menu font.  Allowed values may be found in "freeglut_std.h" on lines 189-195
> (or 215-221, if you prefer).  But we don't have a function call for the
> application to set the menu font.

It would also, to add a minor note, be feasible to use a stroked font
instead of a bitmapped font.  But that would be more work, because
stroked fonts work in model space and use a different set of rendering
functions.  (I know that you know that, John.  I'm not sure if the
originator of the thread knows that---and suspect that they would not
find the stick-figure stroked fonts to be professional.)

I think that the professionalism of the font is a matter of taste,
by the way.  (Which is an argument to let the client fiddle with the
font, but an argument against changing the default/normal font used.)

> Everybody,

>     Would such a function be a useful addition to the "freeglut" API?

This depends on what your goals are for freeglut, in my view.

Is freeglut intended to support powerful, complex, sophisticated,
applications?  If so, then yes, aesthetics like this are important.
So too are things like drawing graphics in menus, and many many other
things that would require changes in freeglut.

If the goal of freeglut is to support demos, simple games and
single-window applications---and nothing more---then I would
contend that adjusting the font is a small bit of inessential chrome
and someone seeking a professional final application will almost
certainly find other (more than aesthetic) issues.  And, as the
font relates to the size of menu labels, which in turn affects many
things in the function of the menus, this API feature has many
hidden relationships in the library.  Although the current
implementation of menu.c is such that these relationships will
probably all be handled correctly, it does add a little "mental
baggage" to any work that people may do on the library.  In this
case, I would think that professionalism is a false goal.

Please note that I am not expressing a view that the feature should
be added or not.  I am expressing an opinion about the relation between
this feature and freeglut's goals.  I think that the answer to your
question can be had by going back to freeglut's core mission.

  "I probably don't know what I'm talking about."

SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play:
Freeglut-developer mailing list