[SciPy-user] SciPy and GUI

Gael Varoquaux gael.varoquaux@normalesup....
Sun Feb 1 15:35:17 CST 2009


On Sun, Feb 01, 2009 at 09:48:32PM +0100, Tim Michelsen wrote:
> > I would use traits (see
> > http://code.enthought.com/projects/traits/documentation.php, and
> > http://code.enthought.com/projects/traits/docs/html/tutorials/traits_ui_scientific_app.html
> > for documentation and a tutorial)
> * Where is the "science" in TraitsUI? (Why do you call it a scientific GUI?)
> 	 E.g. I could also build a Wizard directly with wxPython. So why with 
> Traits?

There are two questions here: 

    1. What is scientific with Traits?
    2. Why Traits rather than raw WxPython?

Answer to 1):

    Per se Traits has nothing scientific and can be used for
    non-scientific applications. Now the people behind Traits do
    scientific computing. As a results Traits integrates perfectly with
    numpy, or Mayavi, or the Chaco visualization library. In addition
    there are plenty of widgets that are very relevant to scientific
    applications (such as slider bars).

Answer to 2):

    Its a question of using the right abstraction level. WxPython is a
    library of widgets, events and eventloops. It forces you to think in
    these terms and not in terms of models and views. Traits makes you
    think in terms of building a model, making it live with a set of
    callbacks, and adding a view on top of it. The code is much clearer
    because it is not riddled with references to 'wx.TextField', and the
    reactive-programming model is much easier to follow than explicit
    registering of callbacks (it is interesting to note that Qt has
    started to move in this direction in Qt4, although the corresponding 
    PyQt code is not terribly Pythonic). Moreover, the event loop is
    mostly hidden to the user, in Traits. This is possible because of the
    implicit View/Model separation and the 'message passing' programming
    style that comes from heavy use of callbacks on attribute modification.
    As a result, threading issues with event loops (which are a really
    bitch) are hidden with Traits: Traits, and TraitsUI is mostly
    thread-safe. In Wx, you will quickly have to understand the fine
    details of the event loop, which is interesting, but quite off-topic
    for the scientific programmer.

    But the really important thing about Traits is that is folds together
    a set of patterns and best-practices, such as validation, model-view
    separation, default-initialization, cheap callbacks/the observer
    pattern. Using Traits puts you on a good path building a good
    architecture to your application. If you are using the raw toolkit
    you can still architecture your application right, but you need more
    experience, more knowledge. It is so easy to mix model and view
    when manipulating widgets, and not an abstraction to them (I did this
    this summer without realizing it, and regretted it a lot much later).

> * I tried the examples.
> What I did not understand is how one can control the buttons below the 
> Traits objects.
> For the first example (section "An object and its representation"), 
> there are 6 buttons in your image:
> Undo, Redo, Revert, OK, Cancel, Help.
> When I execute the code I only get OK, Cancel.

> May you tell how or where to find information how buttons can be contolled?

I can tell you this. You need to write a handler for your view:
http://code.enthought.com/projects/traits/docs/html/TUIUG/handler.html

To give you a short example to do this:

from enthought.traits.api import HasTraits, Int
from enthought.traits.ui.api import View, Handler

class MyHandler(Handler):

    def closed(self, info, is_ok):
        if is_ok:
            print 'User closed the window, and is happy'
        else:
            print 'User closed the window, and is unhappy'


class Model(HasTraits):
    
    a = Int

view = View('a', handler=MyHandler(), buttons=['OK', 'Cancel'])

model = Model()
model.configure_traits(view=view)

However, if you are not programming a reactive application, I would try
to put as little code as possible in the handler, and put the logics in
the code following the 'configure_traits' call. If you need to know if
the user pressed 'OK' or 'Cancel', I would capture this and store it in
the Handler, but I would put the processing logics later on. That's
another case of separating the core logics (called 'model') from the
view-related logics.

> * Input validation: I remember to have seen a example where a Traits
> Window was used to validate (numeric) input. If the user puts in invalid 
> numers, it would turn read.. Do you know about this?

Sure, that's easy: when you specify the traits, you specify its type (in
the above example it is an int), if the user enters a wrong type, the
text box turns read, and the corresponding attribute is not changed.

> * Is there a feature roadmap for traits?
> I would like to know where you intend it to develop it to before I 
> settle on it.

Traits 3 was release 6 months ago. It was a major overhaul (although the
API didn't change much). Ever since development has been fairly limited.
It seems that people are mainly happy with what we have right now. Of
course Traits has limitations (including some design issues, nobody is
perfect). In addition some specific needs might arise. Remember, there is
a company behind Traits. Thus you may see some new developments, or
additions. I don't expect a major change anytime soon.

> It maybe of interest for many prospective beginners to see example 
> applications. Why not listing all accessible applications built with 
> TraitsUI on a website?

Most of them are not open source. The open source ones (SciPyLab, Mayavi)
are fairly complex, and I would advise a beginner to look into them.

> I think that Enthought should put a strong pointer on their website 
> (http://code.enthought.com/) indicating that actually a lot of 
> documentation can also be found on the Trac wiki 
> (https://svn.enthought.com/enthought/wiki).

You probably have a point. Documenting a beast like that is not easy,
believe me :).

HTH,

Gaël


More information about the SciPy-user mailing list