SciPy and GUI

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

scipy & climate data [Re: SciPy and GUI]

Timmie
Administrator
> I'm working with environmental/climate measurement data too. I also
> work with hydrodynamic models and comparing results from these to
> measurement data.

> The measurement data is mainly water quality parameters (Salinity,
> Temperature, Depth, D.O etc). Our group collects data in various bays
> and estuaries in Texas and the last couple of years I've been
> spearheading an effort to make the way data from the field
> instruments (collected by us and by other agencies for us) is QA/QC'd
> and archived in a more systematic and reproducible manner. Original
> procedures involved lots of manual editing and file mangling with
> excel with no record of what had been done & why.

Pierre GM sent me a link to his work off list.
Your work seem to be in the same area of interest. Link up with him.
Please see here:
https://code.launchpad.net/~pierregm/scipy/climpy
http://bazaar.launchpad.net/~pierregm/scipy/climpy/annotate/head%3A/scikits/climpy/doc/source/examples/examples.rst

Regards,
Timmie

_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: SciPy and GUI

Bryan Cole
In reply to this post by Dharhas Pothina

>
> On one hand, I am already using matplotlib and the timeseries toolkit
> extensively in scripts so I'm familiar with them and know that they can
> make pretty much any type of plot I need. Also matplotlib has a large
> community.
>
> On the other hand, chaco seems to have been designed for this type of
> interactive application and the plots I need for the GUI app are simpler
> and are supported by Chaco.

A few weeks back I added a recipe to the scipy wiki for embedding a
matplotlib figure in a Traits app. You can find it at

http://www.scipy.org/EmbeddingInTraitsGUI

BC



_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: SciPy and GUI

Fernando Perez
On Tue, Jan 27, 2009 at 4:19 AM, Bryan Cole <[hidden email]> wrote:

> A few weeks back I added a recipe to the scipy wiki for embedding a
> matplotlib figure in a Traits app. You can find it at
>
> http://www.scipy.org/EmbeddingInTraitsGUI

Excellent!  Just a suggestion: self-contained recipes like this should
always be added as entries to the scipy cookbook rather than as
self-contained pages. It will make it easier to find it later and
keeps the top-level of the site organized:

http://www.scipy.org/Cookbook

Cheers,

f

ps - the cookbook page is timing out right now, after 4 tries.  I
don't know what's wrong with the server...
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: SciPy and GUI

Bryan Cole-2

>
> Excellent!  Just a suggestion: self-contained recipes like this should
> always be added as entries to the scipy cookbook rather than as
> self-contained pages.

It is! It's linked under the Matplotlib cookbook. Since other recipes
concerning embedding mpl in GUIs are linked there, it seemed the right
place for it to go.

BC

> It will make it easier to find it later and
> keeps the top-level of the site organized:



_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: SciPy and GUI

David Warde-Farley-2
On 28-Jan-09, at 5:27 PM, Bryan Cole wrote:

> It is! It's linked under the Matplotlib cookbook. Since other recipes
> concerning embedding mpl in GUIs are linked there, it seemed the right
> place for it to go.

I think what Fernando meant was to create pages as /Cookbook/
MyCookbookRecipe, rather than /MyCookbookRecipe, to make things even  
easier to find in a flat list of wiki pages (and make it clear from  
just the URL that it's part of 'the cookbook').

Cheers,

DWF
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: SciPy and GUI

Bryan Cole-2

> I think what Fernando meant was to create pages as /Cookbook/
> MyCookbookRecipe, rather than /MyCookbookRecipe, to make things even  
> easier to find in a flat list of wiki pages (and make it clear from  
> just the URL that it's part of 'the cookbook').

Ah, I see what you mean now.

I would rename the page as suggested, but I can't see how to do this
("rename page" is greyed out for me). Could someone with more
wiki-permissions than I rename it?

cheers
BC

>
> Cheers,
>
> DWF


_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: SciPy and GUI

Gael Varoquaux
On Thu, Jan 29, 2009 at 07:28:15AM +0000, Bryan Cole wrote:

> > I think what Fernando meant was to create pages as /Cookbook/
> > MyCookbookRecipe, rather than /MyCookbookRecipe, to make things even  
> > easier to find in a flat list of wiki pages (and make it clear from  
> > just the URL that it's part of 'the cookbook').

> Ah, I see what you mean now.

> I would rename the page as suggested, but I can't see how to do this
> ("rename page" is greyed out for me). Could someone with more
> wiki-permissions than I rename it?

Done.

That poor wiki seems overloaded (for instance the cookbook page returns a
server error quite often). I don't know anything about wiki technology,
so I can't really help, but it is a pitty.

Gaël
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: SciPy and GUI

Timmie
Administrator
In reply to this post by Gael Varoquaux
Hello,
Some ideas on adding a GUI to scientif scripts can be found in the
following book:
Python Scripting for Computational Science, by H. P. Langtangen.
http://folk.uio.no/hpl/scripting/

I am currently as well at a point within my developments where user
interaction is needed.
Currently, I see three options with different levels of complexity.

1) use commandline (OptParse) with config files
2) add some simple GUIs that pop up where user input is needed.
3) code a real GUI with a Toolkit.


> 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)
I read your tutorial.
I think it is one of the best I read that are targeting non-programmer
scientists who need to to task specific coding. Your Physics Lab
background shows that you know the difficulties of your readers. Well done!
I shows that GUIs can be created with as little overhead code as possible.

Nevertheless, I have some questions:


* 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?

* 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?

* 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?

* 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.

Others users may also be interested, so I relink to an earlier post:
example application for a starter with TraitsUI
http://thread.gmane.org/gmane.comp.python.enthought.devel/18246

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

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).

Kind regards,
Timmie



_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: SciPy and GUI

Gael Varoquaux
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
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: SciPy and GUI

Timmie
Administrator
Hello!
  > Answer to 2):
>
>     Its a question of using the right abstraction level. WxPython is a
[...]
>     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
Hey, these well formulated explanations really convinced me to look more
closely into ETS and GUI building!


> 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.
This is still something I have to discover closer. I hop to understand
this once I digg deeper.

> 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.
And can there also appear a message like:
Please enter only data of "type"?

>> 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 :).
I looked at all examples and demos in the ETS folder within the Python
XY documentation folder.
There are so many. I really think that the spread if ETS could benefit
from a better advertisement of these demos. Look at the matplotlib
gallery. The new user could quickly imagine why he/she should ponder
about using the library.

Thanks again & kind regards,
Timmie

_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: SciPy and GUI

Gael Varoquaux
On Mon, Feb 02, 2009 at 10:04:28AM +0100, Tim Michelsen wrote:
> Hello!
>   > Answer to 2):

> >     Its a question of using the right abstraction level. WxPython is a
> [...]
> >     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
> Hey, these well formulated explanations really convinced me to look more
> closely into ETS and GUI building!

Well thanks. I actually find that these problems are hard to understand
and to explain and that I do not have enough insight on them, and thus my
explanations are confused and go into circles. But thanks for the
encouragement.

Gaël
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: SciPy and GUI

michael hohn-3
In reply to this post by Lorenzo Isella
Lorenzo Isella <lorenzo.isella <at> gmail.com> writes:

>
> Dear All,
> I hope this is not too off-topic. Given you Python code, relying on
> SciPy for number-crunching, which tools would you use to create a GUI
> in order to allow someone else to use it, without his knowing much (or
> anything) about scipy and programming?I know Python is great for this,
> but I do not know of anything specific.
> Cheers
>
> Lorenzo
>

If you are interested in a general-purpose worksheet-style interface to
Python, you can have a look at the l3gui at
http://l3lang.sourceforge.net, especially example 2.3.

Cheers,
Michael


_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: SciPy and GUI

Robert Cimrman
michael hohn wrote:
> If you are interested in a general-purpose worksheet-style interface to
> Python, you can have a look at the l3gui at
> http://l3lang.sourceforge.net, especially example 2.3.

Very nice!

r.
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
12