Still on python GUI toolkit
Laurent Pointal
laurent.pointal at laposte.net
Tue Nov 20 13:20:50 EST 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