[AstroPy] AstroPy Digest, Vol 81, Issue 12

Thu Jun 20 18:08:27 EDT 2013

On 20-06-2013 22:02, Aldcroft, Thomas wrote:
>
>
>
> On Thu, Jun 20, 2013 at 3:20 PM, Adrian Price-Whelan 
> <adrianmpw at gmail.com <mailto:adrianmpw at gmail.com>> wrote:
>
>     I'm totally lost on what thread I'm responding to, but +100 to what
>     Perry said about GUIs! IMHO there is plenty to keep us busy working on
>     the modeling and backend, and we should focus our efforts on making
>     that code super slick and useable *first*, then worry about a GUI
>     (which, also IMO, are overrated! why do you want to click on your
>     absorption lines anyways??).
>
>
> I understand you are being a bit sarcastic, but I did half my thesis 
> on QSO absorption lines and I'll tell you that being able to click on 
> those lines was a lifesaver.  I wrote a Fortran / PGPLOT-driven GUI 
> tool for analyzing absorption lines which people were still using 10 
> years later.  Suffice to say that GUI's are useful, but I fully agree 
> with comments regarding the separation of computation from interface.
>
> - Tom

Interesting - I did my Master's Thesis on QSO absorption lines, and used 
a fortran/pgplot based GUI for my modeling. VPfit, to be precise.
That is also when I learned what a difference a good GUI can make: Joe 
Liske's VPguess interface to vpfit was a life saver for me. Would your 
work have happened to be on any of those two tools?

It bears repeating again, of course, that any good GUI is characterized 
by the fact that any important setting an be saved and preferably 
manually edited in a configuration file and loaded at a later point.

>
>
>     On Thu, Jun 20, 2013 at 3:09 PM, Perry Greenfield
>     <stsci.perry at gmail.com <mailto:stsci.perry at gmail.com>> wrote:
>     >
>     > On Jun 20, 2013, at 12:34 PM, Erik Tollerud wrote:
>     >
>     >> I'm of mixed minds about traits UI because once you know it you
>     can make great GUIs with it, but I've spent a lot of time
>     troubleshooting people's python installations to get traits to
>     work.  That is, in general it can be tricky to get installed
>     because of all the dependencies.  Maybe this has improved recently
>     with Enthought's Canopy (or other new python distros), but that's
>     been my past experience.
>     >>
>     >> More generally, the view in the astropy core package is that we
>     don't want to put GUIs in the core because GUIs always carry lots
>     of dependencies, which we don't want to be forced to deal with.
>      But part of the whole reason for affiliated packages was to get
>     around this, so we're happy to see GUI-based affiliated packages.
>     >
>     > To expand on the GUI issue a bit. I certainly see the benefit of
>     an interactive GUI for these tools. But they raise a number of
>     issues that the authors should think about.
>     >
>     > 1) They require one to select a windowing system. It would be
>     nice if we standardized on one. Two obvious (but not the only)
>     candidates are Qt and Tkinter. Qt is much more modern, but as far
>     as I can see still presents significant installation issues for
>     some. Tkinter is long in the tooth, but installation issues are
>     generally much fewer. Yes, there's Wx, Gtk, and others, not to
>     mention the whole browser interface issue, which ought to be
>     considered as well.
>     >
>     > 2) I've seen the danger of someone starting right off with a GUI
>     framework for their spectral (or any other kind of tool), and
>     making their computational functionality entirely intertwined with
>     it. I think that is a mistake. Eventually, many would like to
>     script a lot of that functionality, or use it in other contexts.
>     It's really important to keep the core computational stuff
>     independent of the GUI.
>     >
>     > 3) GUI's are expensive to do well, and expensive to make changes
>     to. For that reason I tend to favor the no-GUI approach for the
>     initial functionality as much as possible, and limit the
>     interactions to simpler tools (or simple GUI) until all the pieces
>     are ready for integration into a full GUI interface. It helps
>     accomplish 2) as well, and gives some experience before too much
>     is invested in a GUI design.
>     >
>     > So even if a GUI is needed, it's quite likely a lot of the
>     underlying machinery should go into the core, or at least into a
>     non-GUI package.
>     >
>     > Perry
>     >
>     > _______________________________________________
>     > AstroPy mailing list
>     > AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>     > http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
>     --
>     Adrian M. Price-Whelan ~ Columbia University ~ http://adrian.pw
>     _______________________________________________
>     AstroPy mailing list
>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>     http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130621/f9001653/attachment.html>