[AstroPy] AstroPy Digest, Vol 81, Issue 32
trive at astro.su.se
Wed Jul 3 04:02:15 EDT 2013
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
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,
As an illustration and hopefully inspiration, I have put up a
[standalone version] 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
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,
> 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...
More information about the AstroPy