[AstroPy] AstroPy Digest, Vol 81, Issue 12

[Aldcroft, Thomas]

On Thu, Jun 20, 2013 at 3:20 PM, Adrian Price-Whelan <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



>
> On Thu, Jun 20, 2013 at 3:09 PM, Perry Greenfield <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
> > http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> --
> Adrian M. Price-Whelan ~ Columbia University ~ http://adrian.pw
> _______________________________________________
> 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/20130620/f91df674/attachment.html>