> [menu timeouts]
> Why not let the user configure this time? ...
Sounds good to me, though I'm not sure I'm completely convinced that
there is a valid rationale of having a timeout at all, since I'm a bit
hazy on the reasoning for grabbing the server. Lengthy server grabs
are almost always a Bad Thing and to be avoided. About the only time
I consider doing a grab is when I'm futzing with the colormap and I
don't want some other application gobbling up shared color cells while
I'm in the process of trying to do allocation.
> ... It may not be something
> you would want to create yet more API for, but perhaps a nasty
> global in the forms.h file could be hacked by systems admin
> people (or more reliable users could do with a copy of the
> header used locally, rather than from e.g. /usr/local/include)
I'm all for just adding
fl_set_menu_timeout( int timeout_sec );
At absolute worst, an environment variable or application resource
could be used.
Diddling with the forms.h file is (IMHO) the wrong way to go. First
of all, it breaks the largely consistent API design. It also
contributes to namespace pollution (again, almost *always* a Bad
Thing). Finally, it would be hard to implement that way. If you
include forms.h in several files (quite common) then aren't you going
to get several instantiations and initializations of the same global?
A lot of loader/linker programs will barf on that.
spl
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see
http://bob.usuf2.usuhs.mil/mailserv/xforms.html
Xforms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/