Still on python GUI toolkit

Laurent Pointal laurent.pointal at laposte.net
Tue Nov 20 19:20:50 CET 2001


[posted and mailed]

Luca Fini <lfini at arcetri.astro.it> wrote in
news:Pine.LNX.4.33.0111201217030.31638-100000 at localhost.localdomain: 

> I'm trying to make a sound decision of which GUI toolkit to use for a
> new software project (it is the control and supervision system for a
> complex scientific instrument). My target system is Linux both for
> development and for the final system, although portability to Windows
> coud be a plus. 


Hello,

I have just gone to a Workshop about TACO/TANGO at the European Synchrotron 
Radiation Facility (Grenoble, France) last week. These tools are for 
distributed control systems on very large scientific instruments, but near 
discussions about these tools, there were discussions on experiment control 
and GUI.

See       http://www.esrf.fr/taco/workshop/
and       http://www.esrf.fr/taco/workshop/programme.html
Our own work: http://www.esrf.fr/taco/workshop/pointalSlides.pdf

All the different institute present have projects based on Python for 
scripting.

For GUI, there seem to be no clear choice (ESRF use Tkinter, FRM-II use QT, 
we use wxPython for GUI and IgorPro for plots). One interesting thing which 
appear during discussion is the possibility to use Python for scripting, 
Java and all its RAD and graphic tools for GUI, and to link them together 
(use right tool at the right place).

For our futur projects (I work at on beamlines at LURE, Orsay-France), we 
may go to the following architecture (still to be tested and evaluated):               


                GUI in Java
                    |
  CORBA ORB for Java (OpenORB or other)
                    |
                    |
                    |
     CORBA ORB for Python (omniORBpy)
                    |
              scripting and
           processing in Python


With such a solution, you must define a CORBA object interface, code your 
object in Python using omniORBpy for the CORBA stuff (really very easy), and  
use Java to code a client doing GUI and eventually plots (this is the side I 
must explore, but seeing Java tools, beans assembly possibilities seem 
promising). I'm not sure its the perfect solution for high speed realtime 
display of huge images, but for 80x80 image with 8bpp grayscale, it may not 
be a problem.


We have already a running experiment with wxPython for the GUI, but we use 
Igor Pro (commercial, on windows) for plots. The integration with Igor Pro 
is done via CORBA with omniORBpy in Python, and an Igor Pro plugin using 
omniORB and creating a CORBA object in the Igor process. 
Python act as a client for the Igor Pro CORBA object, this object simply 
define an interface to receive data (simple, 1D, 2D), and users use Igor Pro 
as they do when they read a file (maths on data, plots)... but data come 
magically from Python script and Igor takes care of updating maths and 
plots.

With current speed of computers, this kind of solution work nicely. And you 
can focus on another thing than developing another new data plot system. 
This allow to have data acquisition and GUI and plots on different computers 
(here we have in mind the possibility for scientists to have remote status 
display, and eventually remote control for 24h/24 running experiments). This 
can be adapted on Linux (omniORB is multi-platform), you have just to find a 
data plot program allowing plugins (OpenDave was demonstrated at the 
Workshop, looks promising, but not stable enough curently for realtime plots 
- maybe at beginning of 2002 when they need it on production experiment).

>
...
> I'm still trying to make a choice between PyQt and wxWindows and I'd
> like comments and suggestions on this point.

How, my suggestions are not on these...

> 
> Many thanks,
> 
>                               l.f.

A+

Laurent.



More information about the Python-list mailing list