[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Systems for writing a science app front-end

Vincent.McIntyre@csiro.au wrote:
Interested to hear what people think wrt platforms/systems in which to
write a front-end for a console scientific app (typically long-running).

we're working with
* python & some c++
* Tk for gui at present, thinking of switching to wxwidgets
* matplotlib for plotting
There were some memory leaks with python, but I think all that has been
resolved now.

Tk/tcl seems to be quite popular, perhaps due to its size, or simplicity? Matplotlib looks rather interesting; I'm sure I've come across it in the past, but disregarded it since I was looking for a pure plotting program at the time - I tend to use gnuplot for scripted plots and (xm)grace for line plots.

> The SWIG package was developed to help people bind scripting languages
to drive C or C++ code that does the heavy lifting, such as simulations.
Python is arguably the best supported binding. This might enable your
users to bind their simulation libs to python, then use your frontend
for gui-based control & display. www.swig.org.

Well I did investigate using swig (and later boost.python) some time ago, but TBH I'm currently thinking that it is better to keep the simulation(s) and the frontend(s) separated. Long-running processes are not good to combine with gui's, unlesss using multiple threads - and it is just easier to use multiple processes :)

This may be different if the app is more interactive with the simulation code itself, ie. more cad-like, or if some scripting interface is exposed rather than just a 'design' or fixed parameters.

Oh, and doing it this way is great for reducing bugs - separated modules are always better IMO/E :)

Do others agree?


Reply to: