[AstroPy] AstroPy Digest, Vol 81, Issue 12

[Adrian Price-Whelan]

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??).

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