Hi Rick,

Yes, I've used the 10.6 script in the past with no problem. Personally, all of the software I build on my Mac goes into /usr/local. This can be rationalized as a desire for consistency with other computes that I work with, but it's really just that I don't build enough OS X-specific software to learn about frameworks, etc.

I've learned enough about Frameworks to mostly regret it. ;-) My recollection of the motivation for framework builds is twofold -- one for the access to the native widgets, and the other (possibly the same thing?) was the access to the ObjC frameworks. For instance, you can get bindings to do a lot of things. But with yt, specifically, we have no reason to use any of the ObjC frameworks. So I guess the question is, if the install_script.sh works, do we want to spend *any* effort on maintaining a second set of scripts for the framework builds? Or should we just say adios to them? I see that you've used the 10.6 script, but has the old install_script.sh (or even the current one with INST_BZLIB = 0) worked for you?

I think that not building GUIs by default is reasonable solution to providing a simple and reliable installation method. Web interfaces can limiting, but they're much more portable, and open up a lot of potential, especially given the number of remote systems we work on.

Right now I have a couple things built on yt that might be cool, but might not be: * Fisheye: Tom Abel suggested I try to replicate the Jacques GUI based on YT. This uses Tkinter, is very simple, and basically recreates the ability to zoom, slice, project, change fields, recenter, and so on. It's a couple hundred lines of code. http://bitbucket.org/MatthewTurk/fisheye Requires only the Python stdlib. * Image Panner: This is a google maps style pan-n-scan with a cool colorbar attached. It uses the Chaco GUI, not the web browser, and all the pixelization is still handled by yt. Comes with yt, requires ETS and Qt. * Reason v2: This is essentially just a TVTK GUI, where you can make isocontours and cutting planes in a frame. *This* is kind of cool, but I think the challenge of writing our own marching cubes algorithm in raw GLSL is less than the challenge of getting people to install VTK. Requires basically the entire kitchen sink: Qt, ETS, VTK. * Simple OpenGL widgets: These are widgets for displaying images either stereoscopically or non-stereoscopically in OpenGL, a grid viewer, a grid slicer, and a volume renderer that runs on the hardware. (The volume renderer has some artifact I haven't figured out, but enough works to see the structure.) Requires only PyOpenGL. These are all the GUIs that I believe are currently built on yt that would function if you ran them right now. I only see a future for fisheye and the OpenGL widgets. (And there's a good chance the OpenGL widgets will go away due to a pretty cool possibility coming up in the not-too-distant future.) As for web stuff, there are a couple proof-of-concepts in the repo http://bitbucket.org/MatthewTurk/yt_ajax . These are a Mapquest (not google maps) style interface that pans around an image, and a simple python interpreter. (Neither are secure, so only run if you are sure you want to!) The python interpreter also comes with a convenience function to pass images back to the browser, so you end up with something that looks like: http://yt.enzotools.org/files/simple_repl.png (except I've cut off the web browser around the edges.) Neither of these require anything outside the standard Python library and yt, which I think is what makes them the most attractive to me: you don't *need* anything else installed, connections can be tunnelled over ssh *trivially*, and you can have images passed back and forth simply. Plus, passing HTML from the server to the client allows you to create widgets programmatically, so one could imagine a number of cool mechanisms for interaction. This fits extremely nicely with the "plot window" Jeff is working on. Anyway, this is where I see the future of GUIs in yt: either very raw OpenGL stuff, web stuff with few or (for preference) no external dependencies, or *possibly* Tkinter. What do you think of this possible approach, Rick and others? My personal feeling, and it's taken me a while to come to this, is that web stuff is the only way I see that we could go forward and not have any dependencies, whcih I think is the only way we'll be able to have a GUI that reaches anyone not reading (writing?) this email. Oh, so the upshot is that if we say, "No Native GUIs!" we can probably ditch the 105 and 106 install scripts. +1, -1 to ditching native GUIs, anybody? Best, Matt