Still on python GUI toolkit

[Laurent Pointal]

Fernando Pérez <fperez528 at yahoo.com> wrote in
news:9terl6$s3m$1 at peabody.colorado.edu: 

> Laurent Pointal wrote:
>  
>>                 GUI in Java
>>                     | CORBA ORB for Java (OpenORB or other)
>>                     |
>>                     |
>>                     | CORBA ORB for Python (omniORBpy)
>>                     |
>>               scripting and processing in Python
> 
> Just curious: why the extra Java layers? Naively I'd have the
> impression that from within python alone you can easily do the top part
> of your diagram without needing Java. 

Yes, we have a working wxPython interface on an experiment - but directly 
connected to the multithreaded experiment scripts. We have already CORBA 
between Python experiment scripts and commercial plotting application Igor 
Pro.

> One more language adds overhead
> both of execution and development/maintenance. I'm sure you guys have
> very good reasons for what you're doing but I'm curious. Is it that the
> currently available gui toolkits are that inferior to swing to justify
> the extra complexity? Or do you have other reasons?

Several reason:

-Its not for realtime video or things needing high bandwidth, so execution 
overhead is not a problem.

-Java RAD tools, especially for GUI building, are good and make GUI 
development times shorter. We think of building base interface objects as 
beans, and let advanced users construct their experiment interfaces with 
these beans. We will need a CORBA connection bean too.

-In respect to Sun action (and money...) around Java, the growth of tools is 
quicker than for Python.

-Java is THE language used in many computer learning classes, it will be 
more easy to find Java developers than Python ones (I know, Python is really 
easy to learn).

-Using CORBA for remote control of our experiment scripts: these are for 
experiments running 24h/24, and scientific experiment managers would like to 
be able to operate on the experiment from home to be able to help a user 
without having to move - when possible. It will also be possible to have a 
small experiment status running on desktop computer of experiment managers 
or users (applets & Co).

But we will continue to use Python for experiment scripts, where it fit 
really better than Java (IMHO).
And C/C++ when needing speed with instrument devices :-)

Different tools for different purpose, and connect them together.

Currently I work on the Python side for controling experiments in a common 
reusable framework 'pyexp' - the first priority before the "clickodrome", we 
must have running experiments with that around march 2002. We recently get a 
new coworker which has experiment with Java, and I hope we use his knowledge 
when doing GUI and beans.

> cheers,
> 
> f.

A+

Laurent.