GUI controls for instrumentation

[T. E. Pickering]

we do a lot of instrument interfacing here at the MMT under fedora and
use a variety of things.  most of the code to support our wide-field
instruments is tcl/tk.  we use critcl to pull in dll/.so files to
access C/C++/vendor code from them.  the adaptive optics people use a
combination of tcl/tk, C, and IDL.  the facility spectrographs use
ruby-gnome.  we inflict a wide variety of guis on the telescope
operators.  we still have some left-over perl-tk guis, several systems
are using ruby-gnome, the guiders are largely tcl-tk with a sprinkle
of labview, the wavefront sensor interface is a mix of tcl-tk/blt and
ruby-gnome, and the mirror cell guis are raw X via windx running under
vxworks (bleah!).

i really like ruby-gnome and found it better and easier to use for
very interactive guis than the python or perl bindings.  we need
information to continually update in our windows while maintaining
continuous interactivity.  i find that ruby threads are an easier,
more straightforward way of doing this than managing a bunch of gtk
timeouts or idles.  when i first started using ruby-gnome a few years
ago there was no easy/safe way of using python's threads with its gtk
bindings.  i haven't looked recently to see how that's changed.  it's
too bad ruby's gtk/gnome bindings haven't yet found their way into
fedora extras.  i may have to join up and do it myself....

that said, interface stuff i'm currently working on is utilizing AJAX
techniques to interface with php and ruby back-ends.  so far i'm
finding this a lot more flexible in many ways than using some widget
set thanks to the extreme mutability of DHTML.  i also like the fact
that you can write one piece of software rather than two.  the back-end
generates its own interface.  for other things there's a degree of
clumsiness when dealing with the browser sandbox and trying to get it
to interact with other things on the system.  javascript can't do
system calls while system calls from php/cgi run as user apache.  this
is a deal-breaker for some of our stuff, but not an issue for many
other things.

tim

-- 
+--------------------------------------------------------------------+
|  T. E. Pickering, Ph.D.            |              MMT Observatory  |
|  Assoc. Staff Scientist            |           933 N. Cherry Ave.  |
|  tim at mmto.org  (520) 626-3755      |             Tucson, AZ 85721  |
+--------------------------------------------------------------------+
> Ok, I see you know what you're doing :-)

Either that or I've gotten pretty good at faking it.