GUI for Fortran programs
Lurkos
develop a GUI.
In particular, I could write some MODULEs in Fortran containing all the
required FUNCTIONs and SUBROUTINEs and then write a GUI with an
event-driven approach, calling the required Fortran procedures when
needed.
I also need to have a multiplatform software (Linux, Windows and Mac).
For this reason I tought I could use wxWidgets as a GUI toolset.
Nevertheless there is no direct binding for Fortran in wxWidgets, so
should use a different language (maybe Python or C++) to call Fortran
libraries.
Is there anyone with experiences in this field that could drive me to
the properly how-tos/guides/books?
I'm also open to any suggestion for different GUI toolsets.
P.S.: I prefer to work with open toolkit, thus discarding stuff like
Winteracter (too expensive for me right now).
--
Lurkos
Gib Bogle
I'm doing just this, but using Qt instead of wxWidgets. I started using PyQt,
which is an easier path if you are not familiar with C++. Now I've gone the
full C++ route, in order to reduce the multi-platform software installation
complications. It's also a good way to learn C++, if that appeals to you. I
don't know anything about wxWidgets, but I do get the impression that with Nokia
behind it Qt is establishing itself as the main open-source GUI system. It is a
very impressive package.
Uno
> I'm doing just this, but using Qt instead of wxWidgets. I started using
> PyQt, which is an easier path if you are not familiar with C++. Now
> I've gone the full C++ route, in order to reduce the multi-platform
> software installation complications. It's also a good way to learn C++,
> if that appeals to you. I don't know anything about wxWidgets, but I do
> get the impression that with Nokia behind it Qt is establishing itself
> as the main open-source GUI system. It is a very impressive package.
Sounds interesting. Can you fill in a few of the details?
--
Uno
Arjan
Some time ago, regular visitor of CLF Arjen (1 letter different from
my name) pointed me at TCL to do this and for me it works. My programs
read and write ASCII-files. The GUI is constructed in TCL and this can
be run on any platform and is downloaded for free. You can even link
the TCL-library with your GUI-code to make an executable. What I like
about this approach is the separation of GUI and number-crunching: my
models are "pure" and free from GUI-stuff, the GUI is a separate beast
with just GUI-stuff without any scientific statement that launches
programs or takes action on events.
Arjan
bht
> I would like to write a software using Fortran 95...
> I also need to have a multiplatform software (Linux, Windows and Mac).
I have been writing multiplatform GUIs for Fortran programs for
perhaps 15 years which are in use around the world (one just hit
published 1000 citations!) and can offer some comments and advice. The
simplest and most easily distributable way to do this is to use a
scripting language to create the GUI and have that run free-standing
Fortran images (i.e. .exe files on Windows). Most of my work has been
with Tcl/Tk, but have switched to developing new projects with Python
& wxPython. (PyQt might also be a good choice.) Note that newer Macs
come with wx & python installed and most Linux dists include both, at
least as optional packages.
For ease of writing GUI code, nothing beats Tcl/Tk for me. I find it
easy and intuitive. I really like being able to type in a few lines of
code to see what they do or to open a Tkcon window and examine/set
variables or even change the GUI of a program without even stopping
the event loop in a debugger. Tk is simple to learn. The code is also
quite compact. I have one program that does simple animation, where
the script writes a file and launches a Fortran program in response to
a user moving sliders. The Fortran output is read back in and the
graph is updated in response. Even on older machines it runs as fast
as a human can see the changes happening. (Hint for speed: the Fortran
output is written in the form of simple Tcl commands that can then be
read using the Tcl source command.)
Python is more of a professional-weight tool and offers packages with
extensive numerical capabilities -- computations done with numpy and
scipy can be as fast as Fortran (in fact they may well be done in
Fortran). The wxpython package is confusing (I'm still learning my way
around frames, windows, panels and sizers...) but creates much nicer
looking and more sophisticated GUI's. But, if you want a simple box on
the screen where a user can type a line of input and where that input
shows up in a variable -- that is one line of Tcl/Tk and at least an
order of magnitude more in py/wx. If you have no choice but to link
your Fortran modules directly into the GUI (and I strongly advise to
not do this if at all possible -- file I/O is fast and easy while
mixed-language projects are hard to package and distribute), use f2py
in python. It makes the job much easier.
All of the above is free and open-source, though I recommend the EPD
python dist if you get into use of many python packages. EPD is only
free for academics.
Brian
Albrecht Schlosser
> I would like to write a software using Fortran 95, but I need also to
> develop a GUI.
> In particular, I could write some MODULEs in Fortran containing all the
> required FUNCTIONs and SUBROUTINEs and then write a GUI with an
> event-driven approach, calling the required Fortran procedures when
> needed.
> I also need to have a multiplatform software (Linux, Windows and Mac).
>
> For this reason I tought I could use wxWidgets as a GUI toolset.
> Nevertheless there is no direct binding for Fortran in wxWidgets, so
> should use a different language (maybe Python or C++) to call Fortran
> libraries.
>
> Is there anyone with experiences in this field that could drive me to
> the properly how-tos/guides/books?
> I'm also open to any suggestion for different GUI toolsets.
Take a look at FLTK ( http://www.fltk.org ). It's written in C++,
and I'm not aware of any Fortran bindings, but with a little glue
code in c/c++ you might get it working. What you describe above
would mean that your main program would be written in c++ and
all your working functions and subroutines would be called as
callbacks. This is usually done with a C interface, so if this
would be possible to do with Fortran (as opposed to calling
C functions from Fortran), then it might work.
FLTK is multiplatform software (Linux/Unix(X11), Windows and Mac).
Albrecht
user1
>
>
> For this reason I tought I could use wxWidgets as a GUI toolset.
> Nevertheless there is no direct binding for Fortran in wxWidgets, so
> should use a different language (maybe Python or C++) to call Fortran
> libraries.
>
I've called F77-like code from C++ and wxWidgets without much trouble.
Build a dll from the fortran code, using mingw version of g77 or
gfortran. On the C++ side, declare fortran routines as extern C,
remember that fortran names are lowercased and may have an underscore
appended, and that arguments are passed by reference.
I never tried F95 functions and subroutines contained in a module.
Albrecht Schlosser
> Take a look at FLTK ( http://www.fltk.org ). It's written in C++,
> and I'm not aware of any Fortran bindings, but with a little glue
> code in c/c++ you might get it working.
I was curious, if it would work, so here it is. Although maybe
slightly OT, here's a working demo. It can be compiled with
MinGW/g++ and gfortran (if you have installed FLTK), but of
course also with other dev. tools.
/*
Fortran callback demo (fortran_cb.cxx)
This demo program shows how you can call a Fortran
subroutine in a callback from a FLTK (c++) main program.
Compile and run using:
gfortran -c do_fortran.f90
g++ -o fortran_cb fortran_cb.cxx do_fortran.o `fltk-config --cxxflags --ldflags`
./fortran_cb
do_fortran.f90:
subroutine do_fortran ( num )
implicit none
integer :: num
num = num + 1
end
*/
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Button.H>
#include <FL/Fl_Input.H>
extern "C" {
void do_fortran_ (int *);
}
/*
This is the callback function. It calls the Fortran
subroutine and assigns a new value to the input widget.
*/
void button_cb (Fl_Widget *, void *i) {
int my_number; // number to increment
char buf[20];
Fl_Input *input = (Fl_Input *)i; // the input widget
my_number = atoi(input->value()); // get the current value
for (int i=0; i<500; i++) {
do_fortran_(&my_number); // increment my_number
}
sprintf (buf,"%d",my_number);
input->value(buf); // store the value
}
int main (int argc, char **argv) {
Fl_Window *window = new Fl_Window(200,140);
Fl_Button *button = new Fl_Button(20,20,160,50,"Count (+500)");
Fl_Input *input = new Fl_Input(80,100,60,20,"Value: ");
input->value("0");
window->end();
button->callback(button_cb,input); // attach the callback
window->show(argc, argv);
return Fl::run();
}
/* end of file */
Have fun !
Albrecht
Clive Page
Lurkos <lurkos...@gmail.com> writes
>I would like to write a software using Fortran 95, but I need also to
>develop a GUI.
If fairly simple GUI facilities are all that you need, then the DISLIN
graphics package might be enough (it's not open source, but free for
personal use, check the licence). I wrote this guide not long ago:
http://www.star.le.ac.uk/~cgp/dislinGUI.html
--
Clive Page
GaryScott
> On 01.10.2010, at 16:59, I wrote:
>
A callback loop in GINO:
call gmInit
...
do while (gmAction(callback) \= -1)
if(callback .eq. xxx) then
else if(callback .eq. yyy) then
end if
end do
call gCloseMenu
And, yes, the setup ("...") is just about as easy.
Gib Bogle
I'm not convinced that the way I'm doing things is the best, but it's working.
The GUI has some screens for setting input parameters, options etc. Clicking
the "Run" button invokes the Fortran program, built as a DLL. This opens two
socket connections to the Qt main program, which has the socket handlers running
in separate threads, and reads the input file that was created from the input
screens, and passed as a subroutine argument. As the Fortran code executes info
of various kinds is transmitted to the GUI program via the sockets. One socket
receives data that is used to update line plots showing various program values.
The other displays progress messages of various kinds, and at intervals gets
an instruction to update the 3D graphics display (on another screen), at which
point a file describing the scene, which has been created by the Fortran
program, is read and used to render the scene (with VTK tools). This program
makes good use of my quad-core processor, since the Fortran is using OpenMP,
typically 4 threads. It's now running on Windows XP, Windows 7, Linux Ubuntu,
and Mac OS X.
Reading about the Tk/Tcl alternative, which is so simple to implement, makes me
wonder if I've made things too complicated for myself. Qt is incredibly
powerful, but also a monster.
Wolfgang Kilian
> On 1/10/2010 5:19 p.m., Uno wrote:
>> Gib Bogle wrote:
>>
>>> I'm doing just this, but using Qt instead of wxWidgets. I started
>>> using PyQt,
>>> which is an easier path if you are not familiar with C++. Now I've
>>> gone the
>>> full C++ route, in order to reduce the multi-platform software
>>> installation
>>> complications. It's also a good way to learn C++, if that appeals to
>>> you. I
>>> don't know anything about wxWidgets, but I do get the impression that
>>> with
>>> Nokia behind it Qt is establishing itself as the main open-source GUI
>>> system.
>>> It is a very impressive package.
After playing around with Tcl/TK I also checked out Qt, and for me it
looks much more natural to use: the signal/slot mechanism is a very
straightforward way of GUI thinking. I can recommend it.
Without a native Fortran interface (I started to write one, it's
possible including a working signal/slot mechanism, but it's only a
proof-of-concept right now), one has to write C(++) or Python code to
use it.
-- Wolfgang
--
E-mail: firstnameini...@domain.de
Domain: yahoo
Lurkos
Please correct me if anything is wrong.
1) Standalone Fortran executable, that communicates a Tcl/Tk GUI using
temporary files.
+ Pros: simple and straightforward to implement
+ Cons: need of working directory, the Fortran executable have to run in
"batch" mode (therefore it is not possible to change the input
parameters looking at intermediate results)
2) C/C++ main source, with callbacks to Fortran subroutines or functions
to perform specific tasks.
GUI written in C/C++ using a cross-platform toolkit like Qt, wxWidgets
or FLTK
+ Pros: high flexibility
+ Cons: need to deal with complicated GUI toolkits, need to generate
interfaces for Fortran modules.
3) Fortran source with callback to DISLIN functions.
+ Pros: only one language involved
+ Cons: no RAD (or RAD-like) environment available, only few GUI widgets
implemented
4) Python main source, with callbacks to Fortran subroutines or functions
to perform specific tasks, using f2py to create interfaces.
GUI written with any toolkit supported by Python, like Qt, wxWidgets,
Tk, GTK+.
+ Pros: powerful
+ Cons: need to deal with complicated GUI toolkits, f2py doesn't support
every Fortran code
5) All the code in Python, using Numpy and SciPy. Use of Fortran when
absolutely necessary (Numpy and SciPy can be as fast as Fortran).
+ Pros: simpler than mixed language project
+ Cons: regret abandoning Fortran
--
Lurkos
Lurkos
> If I have understood well, there are these options.
Sorry... I forgot to thank everyone for the suggestions. :)
--
Lurkos
Richard Maine
> If I have understood well, there are these options.
> Please correct me if anything is wrong.
>
> 1) Standalone Fortran executable, that communicates a Tcl/Tk GUI using
> temporary files.
> + Pros: simple and straightforward to implement
> + Cons: need of working directory, the Fortran executable have to run in
> "batch" mode (therefore it is not possible to change the input
> parameters looking at intermediate results)
I haven't been following this thread, partly because I've been on a trip
this last week, but the last con above is either inaccurate or stated in
a way that is confusing to me.
One certainly does not have to use a batch mode to use Tcl/Tk
communicating with a Fortran program. I personally did some interactive
programs that way quite a few years ago. Those programs are still in
active use. The Fortran programs run interactively using standard
input/output for their user interaction. They "know" nothing about the
GUI and in fact were written long before the GUI part was added on. The
GUI is a separate Tcl/Tk script that translates between the GUI actions
and the standard input/output interaction that the Fortran program
expects. None of this is particularly unique to me; I just used the
tools that were clearly designed for it.
They are definitely interactive instead of batch; that's sort of the
whole point of the GUI. And yes, that does mean that users would change
values to try different things in the Fortran program while it was
running.
I'd say that the only problem of significance I ran into was getting a
version of "expect" that worked in MS Windows. I originally intended for
the GUI to be cross-platform. It does do fine on multiple Unix systems
(including Macs). But when I went to try it on Windows, I found that...
let's see... it was a while ago and details escape me. Either the
Windows versions of Tcl/Tk that I had didn't include "expect" or perhaps
they included an "expect", but one missing the very features that I most
needed from it. I seem to recall there being some commercial Tcl/Tk
packages that advertized having a complete implementation of "expect",
but my budget for procurement was exactly zero. (No need to explain to
me how wrong that is in terms of effective use of my time, which was
much more expensive. I know well. But bureaucracies like NASA don't tend
to be driven by such logic.) So I never did get a working windows
version. Not that I really needed one, but there were users of the
Fortran program on WIndows and some of them would have appreciated the
GUI front end. Things might also have changed since I was doing that.
(At some point, I vaguely wondered whether I might be able to "cheat" by
using Cygwin, but I never got around to seriously investigating that.)
"Expect" is central to using tcl/Tk like this, though. Perhaps your
comment is based on not using "expect."
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Nasser M. Abbasi
> Lurkos<lurkos...@gmail.com> wrote:
>
>> If I have understood well, there are these options.
>> Please correct me if anything is wrong.
>>
>> 1) Standalone Fortran executable, that communicates a Tcl/Tk GUI using
>> temporary files.
>> + Pros: simple and straightforward to implement
>> + Cons: need of working directory, the Fortran executable have to run in
>> "batch" mode (therefore it is not possible to change the input
>> parameters looking at intermediate results)
>
> I haven't been following this thread, partly because I've been on a trip
> this last week, but the last con above is either inaccurate or stated in
> a way that is confusing to me.
>
> One certainly does not have to use a batch mode to use Tcl/Tk
> communicating with a Fortran program. I personally did some interactive
> programs that way quite a few years ago. Those programs are still in
> active use. The Fortran programs run interactively using standard
> input/output for their user interaction. They "know" nothing about the
> GUI and in fact were written long before the GUI part was added on. The
> GUI is a separate Tcl/Tk script that translates between the GUI actions
> and the standard input/output interaction that the Fortran program
> expects. None of this is particularly unique to me; I just used the
> tools that were clearly designed for it.
>
Doesn't the above mean that, when a user click on a GUI control, then
the callback associated with that, results in a call (exec) to the
external Fortran program, a .exe, which implements the callback?
This is in a way like CGI works on a server.
But it seems to me this will not be efficient way to do the GUI. Too
much overhead each time to create a new process, load the .exe in its
context, run the program, tear down the process. Creating a process
each time for each callback event.
A function call will always be more efficient. Also, if the callback
needs to pass data to the GUI, or communicate with the GUI for some
reason, it is easier done in a procedure within the same program. Else,
one needs to design a way to pass information back to the GUI from the
external program, which implements the callback. too messy.
Or Am I missing something here?
--Nasser
Richard Maine
> Doesn't the above mean that, when a user click on a GUI control, then
> the callback associated with that, results in a call (exec) to the
> external Fortran program, a .exe, which implements the callback?
No. As I said, the interaction is via standard input/output - *NOT* via
repeatedly invoking executables. The Fortran executable is invoked only
once at the begining. Then a user click on a GUI control causes the
Tcl/Tk GUI to generate text that is fed to the standard input of the
Fortran program. The Fortran program keeps running during the whole
thing.
> A function call will always be more efficient.
Efficiency is quite unlikely to be a big deal in terms of interpreting a
user click. Users are slow - even the fastest of them. It really isn't
going to make any difference whether processing a user click takes a
microsecond or a thousand times that. The number crunching takes orders
of magnitude more time than even a really inefficient user interface.
Things like simplicity are going to be much more important than
efficiency (unless one is using a somewhat loose definition of
"efficiency" whereby it means whatever is important in the context.) If
you are really that excited about efficiency at that level then you
shouldn't be running a GUI at all... but that would be a false economy
in the large majority of cases.
But In any event, it doesn't work anything like you seem to think,
making the above irrelevant.
> Also, if the callback
> needs to pass data to the GUI, or communicate with the GUI for some
> reason, it is easier done in a procedure within the same program. Else,
> one needs to design a way to pass information back to the GUI from the
> external program, which implements the callback. too messy.
>
> Or Am I missing something here?
Yes. Pretty much the whole thing. I suggest rereading my prior post. To
repeat some points of it....
The interaction between the GUI and the Fortran program is through
standard input/output. No, it does *NOT* involve multiple executions of
executables. Recall that I said the Fortran program was written before
the GUI. I don't mean just barely before, being designed for running
with the GUI. I mean it was written and in use for many years before
there was even a thought of doing a GUI. It has no special provisions
for the GUI, but just runs like interactive programs always did in the
days before GUIs. (Well, I did make some *VERY* minor mods to simplify
the interactions; mostly I added some outputs to have the program
explicitly announce when some commands were completed instead of just
putting out its command prompt; that made it simpler for the GUI to
parse the output.)
The GUI generates text commands on standard input and parses the Fortran
programs standard output. I sometimes describe it as the GUI "knowing"
how to run the Fortran program.
A nice resulting feature is that you can still run the Fortran program
without the GUI if there happens to be reason for that (though pretty
much all of my users rapidly switched to using the GUI except for those
users stuck on Windows machines, where I didn't have the GUI working).
A someone else mentioned, the Tcl/Tk code is fairly compact too. My GUI
is only about 1000 lines of Tcl/Tk script to run a Fortran program of
maybe 15,000 lines (depending exactly what parts you include in the line
count of the Fortran program). Admitedly, I vainly think I did a decent
job of abstracting things such that the same lines of GUI script serve
what would have for multiple screens, but the interpreted nature of
Tcl/Tk encourages that.
e p chandler
"Richard Maine" wrote
> Nasser M. Abbasi wrote
>> Doesn't the above mean that, when a user click on a GUI control, then
>> the callback associated with that, results in a call (exec) to the
>> external Fortran program, a .exe, which implements the callback?
> No. As I said, the interaction is via standard input/output - *NOT* via
> repeatedly invoking executables. The Fortran executable is invoked only
> once at the begining.
The problem is being able to glue the two programs together so that they go
through the software version of a "null modem". The output of A is fed to
the input of B and the output of B is fed to the input of A.
> all of my users rapidly switched to using the GUI except for those
> users stuck on Windows machines
Even on Windows, input and output can be redirected. So all that is needed
is a supervisor program that invokes A and B while hooking up the plumbing.
Richard Maine
> "Richard Maine" wrote
> > ...As I said, the interaction is via standard input/output - *NOT* via
> > repeatedly invoking executables. The Fortran executable is invoked only
> > once at the begining.
>
> The problem is being able to glue the two programs together so that they go
> through the software version of a "null modem". The output of A is fed to
> the input of B and the output of B is fed to the input of A.
See the previously mentioned "expect". I wouldn't really describe its
operation that way.
> > all of my users rapidly switched to using the GUI except for those
> > users stuck on Windows machines
>
> Even on Windows, input and output can be redirected. So all that is needed
> is a supervisor program that invokes A and B while hooking up the plumbing.
Expect does a *LOT* more than just connecting the plumbing. The name
gives a hint of some of it. See its docs or other easily found material
if you care about the details. Reinvent all those wheels if you feel so
inclined. I didn't. Had I tried to do so, I'm sure it would have taken a
lot more than the 1,000 lines of code that I mentioned.
A quick skim isn't being sufficient to remind me of what problem I had
with expect for Windows. Might possibly have been the missing
implementation of exp_interact, but it looks like that was optional for
my app anyway.
nm...@cam.ac.uk
Richard Maine <nos...@see.signature> wrote:
>e p chandler <ep...@juno.com> wrote:
>
>> > ...As I said, the interaction is via standard input/output - *NOT* via
>> > repeatedly invoking executables. The Fortran executable is invoked only
>> > once at the begining.
>>
>> The problem is being able to glue the two programs together so that they go
>> through the software version of a "null modem". The output of A is fed to
>> the input of B and the output of B is fed to the input of A.
Ooh! That's a juicy one! Duplex pipes! Yummy!
>See the previously mentioned "expect". I wouldn't really describe its
>operation that way.
>
>> > all of my users rapidly switched to using the GUI except for those
>> > users stuck on Windows machines
>>
>> Even on Windows, input and output can be redirected. So all that is needed
>> is a supervisor program that invokes A and B while hooking up the plumbing.
>
>Expect does a *LOT* more than just connecting the plumbing. The name
>gives a hint of some of it. See its docs or other easily found material
>if you care about the details. Reinvent all those wheels if you feel so
>inclined. I didn't. Had I tried to do so, I'm sure it would have taken a
>lot more than the 1,000 lines of code that I mentioned.
It would need to, even if it is JUST connecting a duplex pipe. You
can get deadlock with some programs as soon as there is ANY buffering;
and, without it, others run like drains. Handling exceptions (even
close) is equally interesting. Even better, few languages have any
concept of a pure stream (i.e. NO positioning), and far too many
implementations allow such operations on pipes or even use them
internally.
I teach how to glue programs together, and advise ordinary programmers
that this area is a minefield.
Regards,
Nick Maclaren.
e p chandler
<nm...@cam.ac.uk> wrote in message news:i8c52p$8hf$1...@gosset.csi.cam.ac.uk...
Of course *just* after posting it I realized how silly my idea was, I had
forgotten about the problems of handshaking or the "deadly embrace". At
least I said "supervisor program". But of course I oversimplified something
I *don't* intend to write. What I really wanted to describe was a comm
program that I used back in the DOS days. It allowed me to write a script
that it interpreted. This dialed up a remote computer, logged in, retrieved
some net news, captured the output and logged off. It had some facilities
for handling error conditions like no dial tone, number busy, various
timeouts, etc, matching responses, etc. The remote machine had no idea that
it was being driven by a computer program, not a human user at the keyboard.
What I was trying to explain quickly was a type of comm program I had used
back in the DOS days. It dialed up a remote computer and executed a script.
My computer fed commands to a remote computer, captured its output, and then
logged off.
e p chandler
"Richard Maine" <nos...@see.signature> wrote in message
news:1jptckk.2ppsne14rt20wN%nos...@see.signature...
>e p chandler <ep...@juno.com> wrote:
>
>> "Richard Maine" wrote
>
>> > ...As I said, the interaction is via standard input/output - *NOT* via
>> > repeatedly invoking executables. The Fortran executable is invoked only
>> > once at the begining.
>>
>> The problem is being able to glue the two programs together so that they
>> go
>> through the software version of a "null modem". The output of A is fed to
>> the input of B and the output of B is fed to the input of A.
>
> See the previously mentioned "expect". I wouldn't really describe its
> operation that way.
>
>> > all of my users rapidly switched to using the GUI except for those
>> > users stuck on Windows machines
>>
>> Even on Windows, input and output can be redirected. So all that is
>> needed
>> is a supervisor program that invokes A and B while hooking up the
>> plumbing.
>
> Expect does a *LOT* more than just connecting the plumbing. The name
> gives a hint of some of it. See its docs or other easily found material
> if you care about the details. Reinvent all those wheels if you feel so
> inclined. I didn't. Had I tried to do so, I'm sure it would have taken a
> lot more than the 1,000 lines of code that I mentioned.
See my other response. My point was that it should be do-able on Windows
even if it isn't easy.
Two programs converse with each other. Instead of being on two different
computers, they are on the same computer.
> A quick skim isn't being sufficient to remind me of what problem I had
> with expect for Windows. Might possibly have been the missing
> implementation of exp_interact, but it looks like that was optional for
> my app anyway.
Apparently there is a version of expect for Windows. I don't know how well
it works or does not work but it's from ActiveState. IIRC this is commercial
software.
Gary L. Scott
It is a horrible overcomplicated way. It has its uses, but 99% of GUIs
don't need that structure. GINO does not use that type of callback and
it works extremely well.
snip
Clive Page
Lurkos <lurkos...@gmail.com> writes
>If I have understood well, there are these options.
That seems a good summary. But by fortuitously choosing the right
search terms, I just came across this blog page with a much longer set
of options that might be of interest:
http://fortran-gui.blogspot.com/
Also, I think the Tcl/Tk solution does support interactive programming -
I haven't used it myself but have made use of applications that others
have created this way. Also: as far as I can see the windows version of
expect is now included in the community edition of Activestate's Active
Tcl product, so it is essentially free for personal use.
--
Clive Page
Lurkos
>> 1) Standalone Fortran executable, that communicates a Tcl/Tk GUI using
>> temporary files.
>> + Pros: simple and straightforward to implement
>> + Cons: need of working directory, the Fortran executable have to run in
>> "batch" mode (therefore it is not possible to change the input
>> parameters looking at intermediate results)
[...]
> "Expect" is central to using tcl/Tk like this, though. Perhaps your
> comment is based on not using "expect."
You're right. I understood the use of multiple executables, everyone
called for every user interaction with the GUI ... and I was wrong.
If the Tcl script parses the output of the Fortran program, there will
be no need to work in "batch" mode.
However it seems that this approach is more complicated compared to pure
Python.
Which approach would you suggest to me?
Fortran + Tcl/Tk + PLPLOT
or
Python + SciPy/NumPy + Matplotlib
or
mixed language project including C/C++
If I understood well, Python is a simpler approach.
If it is as fast as Fortran, it seems that there would be no reason to
use Fortran anymore... :/
--
Lurkos
fj
> *Richard Maine* wrote:
>
>>> 1) Standalone Fortran executable, that communicates a Tcl/Tk GUI using
>>> temporary files.
>>> + Pros: simple and straightforward to implement
>>> + Cons: need of working directory, the Fortran executable have to run in
>>> "batch" mode (therefore it is not possible to change the input
>>> parameters looking at intermediate results)
> [...]
>> "Expect" is central to using tcl/Tk like this, though. Perhaps your
>> comment is based on not using "expect."
>
> You're right. I understood the use of multiple executables, everyone
> called for every user interaction with the GUI ... and I was wrong.
> If the Tcl script parses the output of the Fortran program, there will
> be no need to work in "batch" mode.
>
> However it seems that this approach is more complicated compared to pure
> Python.
>
> Which approach would you suggest to me?
> Fortran + Tcl/Tk + PLPLOT
> or
> Python + SciPy/NumPy + Matplotlib
> or
> mixed language project including C/C++
They are still other approaches like FORTRAN+JAVA. I use for instance the
JAPI software which allows the programmer to build up a cross platform GUI
easily will free tools.
On UNIX, however, I prefer X11 which is faster than JAPI but also much more
complicated.
>
> If I understood well, Python is a simpler approach.
> If it is as fast as Fortran, it seems that there would be no reason to
> use Fortran anymore... :/
Python is just 100 times slower than FORTRAN or C, except if you develop new
Python modules ... written in C, C++ or FORTRAN !
>
--
François Jacq
Lurkos
>> Which approach would you suggest to me?
>> Fortran + Tcl/Tk + PLPLOT
>> or
>> Python + SciPy/NumPy + Matplotlib
>> or
>> mixed language project including C/C++
> They are still other approaches like FORTRAN+JAVA. I use for instance the
> JAPI software which allows the programmer to build up a cross platform GUI
> easily will free tools.
Right.
BTW It seems that JAPI is abandoned and/or it doesn't support 64 bit.
> On UNIX, however, I prefer X11 which is faster than JAPI but also much more
> complicated.
Direct X11 bindings?
>> If I understood well, Python is a simpler approach.
>> If it is as fast as Fortran, it seems that there would be no reason to
>> use Fortran anymore... :/
> Python is just 100 times slower than FORTRAN or C, except if you develop new
> Python modules ... written in C, C++ or FORTRAN !
Even with SciPy/NumPy (so not "pure" Python)?
If the answer is "yes", I will not follow the only-Python way.
fj
> *fj* wrote:
>>> Which approach would you suggest to me?
>>> Fortran + Tcl/Tk + PLPLOT
>>> or
>>> Python + SciPy/NumPy + Matplotlib
>>> or
>>> mixed language project including C/C++
>> They are still other approaches like FORTRAN+JAVA. I use for instance the
>> JAPI software which allows the programmer to build up a cross platform
>> GUI easily will free tools.
>
> Right.
> BTW It seems that JAPI is abandoned and/or it doesn't support 64 bit.
>
>> On UNIX, however, I prefer X11 which is faster than JAPI but also much
>> more complicated.
>
> Direct X11 bindings?
With a C interface because I wrote that a long time ago. Today, I would you
use the iso_c_binding module of F2003.
>
>>> If I understood well, Python is a simpler approach.
>>> If it is as fast as Fortran, it seems that there would be no reason to
>>> use Fortran anymore... :/
>> Python is just 100 times slower than FORTRAN or C, except if you develop
>> new Python modules ... written in C, C++ or FORTRAN !
>
> Even with SciPy/NumPy (so not "pure" Python)?
> If the answer is "yes", I will not follow the only-Python way.
If you use ScSciPy/NumPyiPy, then you get much better performances because
these modules are written in C, not in Python.
--
François Jacq
dpb
...
> Expect does a *LOT* more than just connecting the plumbing. The name
> gives a hint of some of it. See its docs or other easily found material
> if you care about the details. Reinvent all those wheels if you feel so
> inclined. I didn't. Had I tried to do so, I'm sure it would have taken a
> lot more than the 1,000 lines of code that I mentioned.
>
> A quick skim isn't being sufficient to remind me of what problem I had
> with expect for Windows. Might possibly have been the missing
> implementation of exp_interact, but it looks like that was optional for
> my app anyway.
It's been a number of years now since I last played with it, what I ran
into in an evaluation/proposal to a potential client (never funded so
wasn't pursued) where I ran into trouble was had to incorporate a
system-specific flush() call in the Fortran for expect() to always see a
timely response.
Was going to be doable I felt so I made the proposal but wasn't quite as
clean as I would have liked. The primary client interface person
retired before a decision was made and the heir wasn't so interested in
the project so it died.
Consequently, I don't know if that was a figment of an early Windows
incorporation of Tcl later fixed or a "feature" of a particular compiler
(at the time the Fortran compiler used was Watcom F77). The only thing
that was done was it was converted from OS/2 to NT4 and the port to CVF
(good choice there, eh? :) ) was made but not the GUI so I never tried
the Tcl/Tk trick w/ CVF-built version to see if symptoms were any
different or not.
In theory seemed pretty straightforward; don't know what trouble I'd
have been in if the decision had been to go ahead.... :)
--
JB
> Python + SciPy/NumPy + Matplotlib
> or
> mixed language project including C/C++
>
> If I understood well, Python is a simpler approach.
> If it is as fast as Fortran, it seems that there would be no reason to
> use Fortran anymore... :/
As mentioned, Python itself is slow compared to Fortran. Very
slow. But depending on what you're doing, it can be fast enough. And
by using code written in lower level languages such as Fortran, slow
parts of the program can be sped up. Included in numpy is a tool
called f2py that allows you to create interfaces to Fortran code; it's
not perfect but still somewhat decent. See e.g.
http://www.scipy.org/PerformancePython
--
JB
richar...@gmail.com
> > I would like to write a software using Fortran 95, but I need also to
> > develop a GUI.
> > required FUNCTIONs and SUBROUTINEs and then write a GUI with an
> > event-driven approach, calling the required Fortran procedures when
> > needed.
> > I also need to have a multiplatform software (Linux, Windows and Mac).
> >
> > Nevertheless there is no direct binding for Fortran in wxWidgets, so
> > should use a different language (maybe Python or C++) to call Fortran
> > libraries.
> >
> > the properly how-tos/guides/books?
> > I'm also open to any suggestion for different GUI toolsets.
> >
> > Winteracter (too expensive for me right now).
>
> I'm doing just this, but using Qt instead of wxWidgets. I started using PyQt,
> which is an easier path if you are not familiar with C++. Now I've gone the
> full C++ route, in order to reduce the multi-platform software installation
> complications. It's also a good way to learn C++, if that appeals to you. I
> don't know anything about wxWidgets, but I do get the impression that with Nokia
> behind it Qt is establishing itself as the main open-source GUI system. It is a
> very impressive package.
I'm now also thinking of using Qt C++ GUI with fortran source program. I've been mining online tutorial resources directly regarding how to call fortran program in Qt C++. Could you provide some of your learning resources or experiences on this topic? Thanks.
Myroslav Zapukhlyak
Wolfgang Kilian
project was abandoned. It may be that I commented on this in the old
thread that you necro'ed above, or in another thread.
It may all be outdated now, but the main idea was:
- write C wrappers for all Qt functionality that I want to use. You
can't call C++ classes/methods directly from Fortran, but you can call C
functions.
- work around the fact that Qt is (or was) not real C++, but some
special language that gets preprocessed before producing actual C++
code. I don't know whether this is still the case, but it was a major
inconvenience. I came to the conclusion that some preprocessing is
required also on the Fortran side - I used the M4 preprocessor for that
purpose.
- create a basic Fortran derived type which contains, as its core, a C
pointer to an arbitrary C++/Qt object.
- mirror the Qt class hierarchy by a corresponding Fortran
type-extension hierarchy. The Fortran hierarchy can't access the C++
hierarchy directly, but it can control which C functions are called for
the stored (c_ptr) object handles, and thus mimic the C++ class hierarchy.
All this can become a major effort, in particular if you want to access
more than a few classes and methods. Also, the Qt API may change with
new versions. It may be unnecessary to construct an object-oriented API
on the Fortran side. However, I'd rather recommend to first look for
alternatives. You may search this newsgroup. For our own project, we
moved to a Javascript/node.js GUI. This appears to be most portable and
accessible to users (web browser). You can make node.js talk to Fortran.
JerryD
done already. Everything native Fortran with use modules
https://github.com/jerryd/gtk-fortran
Plenty examples as well.
Cheers,
Jerry