[AstroPy] AstroPy Digest, Vol 81, Issue 12
Thøger Emil Rivera-Thorsen
Thu Jun 20 16:59:57 CDT 2013
On 20-06-2013 21:20, Adrian Price-Whelan 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??).
Most of our work doesn't require a GUI, but a few tasks can be helped
immensely by a good one.
One of these, but not the only one, is the case of having to give a good
initial guess to a fitting package, if you have many lines and many
components and many tied, frozen or thawed parameters.
Something that is vitally important for writing a good GUI, IMO, is
reproducibility, which means that pretty much all settings that one
creates should be possible to write into a script or into the model or
something, so one doesn't have to rely on one's shaky and
coffee-trembling hands to find the same settings multiple times.
> On Thu, Jun 20, 2013 at 3:09 PM, Perry Greenfield <email@example.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.
>> AstroPy mailing list
More information about the AstroPy