[AstroPy] AstroPy Digest, Vol 81, Issue 32

[Thøger Rivera-Thorsen]

Pardon me for resurrecting this thread; I wanted to reply immediately 
but have been swamped so I could not.

My problem with a matplotlib-based GUI is that, as far as I can see, it 
is bound to be essentially linear. It is do-this-then-that, and if we 
are lucky, we can reiterate (some older interfaces, like native VPfit, 
don't even allow for that - one wrong click, and you must start over).  
It does not seem very well fit for reactive/event-driven programming, 
where each view is an equal, first-class citizen that can all manipulate 
the same underlying object, the model.

I am worried that the same will be the case for any IPython 
Notebook-based GUI, at least until the JS rendering capabilities have 
matured considerably, and as far as I can see, making the transition 
from a click-and-draggable script to a fully grown GUI would require an 
entire HTML/JS/JSON/whatever-based framework to be created first. 
Widgets, layout engine etc., unless something already exists that I am 
aware of?

The logging feature of matplotlib is great, but as the workflow with an 
interactive app often consists of a lot of trial-and-error, simply 
saving this as a script to recreate it would run a lot of actions that 
are later undone or simply irrelevant.

One basically defines two different kinds of variables in a GUI:

* Some that are part of the model and the science which are the 
interesting ones. We want to keep only the most recent versions of these 
(not discussing undo history for now).
* Some that are simply state variables defining the visual 
representation and aiding in the internal communication between 
submodules of the interface. There is no need to keep these, as they 
only drown the relevant information and can be easily, if not trivially, 
recreated.

As an illustration and hopefully inspiration, I have put up a 
[standalone version][1] of the line profile builder from my `grism` 
project on GitHub now. It requires scipy, pandas, Chaco, Traits and 
TraitsUI. It works as a GUI, but all variables in the ProfileEditor 
class instance (which, due to my lacking skills when I started writing 
it, also contains the model) can simultaneously be updated from the 
(I)Python prompt from which it was instantiated. This means that the 
interface can be kept clean by only containing tasks that are not 
actually easier to perform from the prompt IMO there is no reason to 
fill it up with tasks like loading ilne lists etc., as this is much 
easier done from the prompt with a clever convenience function).

As has been mentioned before, the dependency on Traits(UI), chaco and 
Pandas may not be very suitable for building an astropy-affiliated 
package, but at least I hope some of the design philosophy can be of 
some use.

Cheers,
Emil

[1]: https://github.com/thriveth/lpbuilder

On 2013-06-26 17:47, Adam wrote:
>> Any GUI that involves processes like selecting absorption lines or setting
>> initial guesses for fits should be able to record the process as a script
>> (either in a simple DSL or even as executable code) that can reproduce the exact
>> steps taken without invoking the GUI at all.
> Great point.  It's actually fairly easy to do in matplotlib: you can
> just make your "event manager" routine record a history of events,
> e.g.:
> self.event_history.append(event)
>
> and as long as you have one overarching event manager for the GUI
> (which is probably an important design decision...), it should be able
> to track
> exactly what has been done and repeat it.
>
> That said, events can be tied to individual axes, so if a window is
> closed, it would be essential to re-create that window in the same
> state it was originally initialized.
>
> Anyway, 2 cents on GUI design...