[AstroPy] AstroPy Digest, Vol 81, Issue 12

[Matthew Turk]

On Fri, Jun 21, 2013 at 8:47 AM, Chris Beaumont <beaumont at hawaii.edu> wrote:
> 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.
>

Since Traits came up earlier, it's worth mentioning that Mayavi is a
good example of using Traits to generate scripts that reproduce an
interactive workflow.  It functions very similarly to how DP lays
things out.

-Matt

>
> 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
> ************************************
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>