[AstroPy] AstroPy Digest, Vol 81, Issue 12

[Chris Beaumont]

For those interested and unaware, many of the patterns in the Design
Patterns book (
http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612,
also easily found on google) deal with enabling this kind of functionality.
Not coming from a formal CS background, that book taught me a lot about
good application design.

In particular, the "Command" pattern deals with encapsulating state, and
making it more reproducible. The basic idea is to map GUI interactions into
explicit request/command objects -- the GUI code creates and fires off
these commands, which the backend responds to. This allows you to keep a
log of commands, which you can use to recreate state. You can also create a
second, scripting interface for building these commands, and even write a
translation layer to convert a command log to scripting layer calls.


The ChIPS people used this approach for Chandra (
http://cxc.harvard.edu/chips4.4/index.html), and that code has lots of good
examples.

chris


On Fri, Jun 21, 2013 at 7:58 AM, Perry Greenfield <stsci.perry at gmail.com>wrote:

>
> On Jun 20, 2013, at 5:59 PM, Thøger Emil Rivera-Thorsen wrote:
>
> > 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.
> >
> > /Emil
>
> Yes, I've long felt that was a critical element to a good GUI. They are
> great to play with the data, and how to view the data. But at some point,
> one wants to be able to repeat that easily, either to do batch processing,
> replicate the results (perhaps to tweak a bit more), or be consistent in
> the processing of other similar data. It would be even better if the GUI
> could save a script that effectively recreates what was done without
> requiring any interaction (rather than a lot of hidden machinery to
> recreate the state).
>
> Perry
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



-- 
************************************
Chris Beaumont
Graduate Student
Institute for Astronomy
University of Hawaii at Manoa
2680 Woodlawn Drive
Honolulu, HI 96822
www.ifa.hawaii.edu/~beaumont
************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130621/2007d733/attachment.html>