GTK+ and Fortran 2003
vincenzo
it is four years since my last post in comp.lang.fortran. I am still
looking for an alternative to using CVF6.5 and his Quickwin library to
create windows.
I read with interest Tobias Burnus' post on the 2nd May 2007 13:10: he
gives a little example of a Fortran 2003 program creating an empty GTK
+ window using ISO_C_BINDING. And it works well (I tested it under
Linux with gfortran).
But you need to create interfaces for all the GTK+ functions you need.
It seems a possibility to ease that work would be to use the C wrapper
TCL program written by Arjen Markus (8th Feb 2008, 9:27 post),
included in FLIBS, and described here : http://wiki.tcl.tk/20756.
So my two questions are:
1) Has someone progress toward such an interface ?
2) Has someone tried to make an interface to Qt library ? (it seems Qt
is written in C++ and I do not know if the ISO_C_BINDING can be used
with C++)
Sincerely yours
Vincent MAGNIN
Institut d'Electronique, de Microélectronique et de Nanotechnologie
France
nm...@cam.ac.uk
vincenzo <vincent...@libertysurf.fr> wrote:
>
>2) Has someone tried to make an interface to Qt library ? (it seems Qt
>is written in C++ and I do not know if the ISO_C_BINDING can be used
>with C++)
To answer the meta-question: yes, provided that you use only the
C90/Fortran77 subset for the interface, and watch out for "gotchas".
Formally, that is not required but, in practice, it's reliable;
it's sort-of expected by the Fortran and C++ standards, at least
as far as the interface goes.
The most likely "gotcha" is memory allocation, but anyone foolish
enough to use any of the advanced features of Fortran or C++ in a
way that they have ANY effect on the other will discover others.
For example, NEVER use C++ exceptions if there are any Fortran
procedures in the call chain between the raise and the handler.
Regards,
Nick Maclaren.
James Van Buskirk
news:d27d1613-9e01-47f3...@m7g2000vbn.googlegroups.com...
> I read with interest Tobias Burnus' post on the 2nd May 2007 13:10: he
> gives a little example of a Fortran 2003 program creating an empty GTK
> + window using ISO_C_BINDING. And it works well (I tested it under
> Linux with gfortran).
How are you supposed to translate stuff like:
G_CONST_RETURN gchar *gtk_about_dialog_get_program_name(GtkAboutDialog
*about);
void gtk_about_dialog_set_program_name(GtkAboutDialog
*about,const gchar *name);
?
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Wolfgang Kilian
> 2) Has someone tried to make an interface to Qt library ? (it seems Qt
> is written in C++ and I do not know if the ISO_C_BINDING can be used
> with C++)
Actually, yes. I wrote a (proof of concept for) a Qt-Fortran interface
some two years ago. I'd like to continue the project, but didn't so far
due to lack of time. It's probably not in a state that you can adopt it
without expanding (a lot).
iso_c_binding is sufficient if you write extern "C" interfaces (in C++
code) for all C++ functions that you want to access. (If you want to
implement all of Qt, that would be quite some work ...) The Qt data
objects are kept opaque and accessed as type(C_PTR). One of the tricky
parts is to enable Qt's unique signal/slot mechanism. Qt implements it
by a special preprocessor that generates 'invisible' C++ code before
compilation. I found a Fortran interface solution that works, but I
also use a preprocessor to keep the user code simple (M4).
I took it as a first exercise in OO programming in Fortran; it's
possible and convenient to mirror the Qt class hierarchy in a
corresponding type hierarchy in Fortran.
-- Wolfgang
>
> Sincerely yours
> Vincent MAGNIN
> Institut d'Electronique, de Microélectronique et de Nanotechnologie
> France
--
E-mail: firstnameini...@domain.de
Domain: yahoo
vincenzo
> Actually, yes. I wrote a (proof of concept for) a Qt-Fortran interface
> some two years ago. I'd like to continue the project, but didn't so far
> due to lack of time. It's probably not in a state that you can adopt it
> without expanding (a lot).
>
> iso_c_binding is sufficient if you write extern "C" interfaces (in C++
> code) for all C++ functions that you want to access. (If you want to
> implement all of Qt, that would be quite some work ...) The Qt data
> objects are kept opaque and accessed as type(C_PTR). One of the tricky
> parts is to enable Qt's unique signal/slot mechanism. Qt implements it
> by a special preprocessor that generates 'invisible' C++ code before
> compilation. I found a Fortran interface solution that works, but I
> also use a preprocessor to keep the user code simple (M4).
>
Thank you Wolfgang for these informations.
So, it's possible to interface with Qt but it seems more complicated
than with GTK+. Concerning Tobias Burnus' GTK+ example, I successfully
compiled it under windows and linux; it's pure Fortran and I only
needed to change the name of the gkt library in the compilation
command line.
Vincent
vincenzo
> How are you supposed to translate stuff like:
>
> G_CONST_RETURN gchar *gtk_about_dialog_get_program_name(GtkAboutDialog
> *about);
> void gtk_about_dialog_set_program_name(GtkAboutDialog
> *about,const gchar *name);
>
I do not know, but I think that I need only a little subset of GTK+
functions, perhaps 20 or 30. My needs are:
- create a parent window,
- create several child windows, one for text and the others for
graphism,
- draw colored pixels and lines,
- write with fonts in those pictures.
My plan would be:
1) To prototype the GUI in Python (using pyGTK) in order to learn GTK+
basics and to identify the functions I need,
2) to learn how to use ISO_C_BINDING in Fortran 2003 and to revise my
C language (my last C program was 15 years ago...)
3) to write the interfaces in Fortran and to try to obtain the same
GUI than in Python.
Vincent
James Van Buskirk
The example I gave above shows two procedures with the same name,
one of which is a subroutine and the other a function. There
must be some kind of name mangling going on so the linker can
tell them apart.
Graphics just seems really hard in Fortran. I was trying to
do essentially "Hello, world" in OpenGL and I kept my attempt
under 10 kLOC and it almost works, but I stayed up most of
last night and there is one subtle point that seems to keep
it from working. What do you do when you have a problem like
this? Nobody that does graphics or Windows can do anything
with the program because it's in Fortran, and nobody that
does Fortran can help because it's Windows specific. I've
gone over the documentation for Fortran, Windows, and OpenGL
and printed out all the function results to a file and they're
the same when the program works correctly and when it doesn't.
I am just stumped.
vincenzo
> one of which is a subroutine and the other a function. There
> must be some kind of name mangling going on so the linker can
> tell them apart.
James, I can only hope I won't need the two of them in the same
program ! ;-)
> Graphics just seems really hard in Fortran.
An eternal problem... It is what we call in french "un serpent de
mer" (a sea snake), surfacing quite regularly in comp.lang.fortran !
But with no solution satisfying a majority.
> I was trying to
> do essentially "Hello, world" in OpenGL and I kept my attempt
> under 10 kLOC and it almost works, but I stayed up most of
> last night and there is one subtle point that seems to keep
> it from working. What do you do when you have a problem like
> this? Nobody that does graphics or Windows can do anything
> with the program because it's in Fortran, and nobody that
> does Fortran can help because it's Windows specific. I've
> gone over the documentation for Fortran, Windows, and OpenGL
> and printed out all the function results to a file and they're
> the same when the program works correctly and when it doesn't.
> I am just stumped.
I tried five years ago OpenGL but I do not remember if I succeeded.
Anyway it seems that you can not have true child windows within an
OpenGL window. It is not a window manager.
I began to use the ancestor of CVF (Microsoft Fortran Powerstation)
during my PhD in 1995-1998. The QuickWin library was perfect for my
needs, and I am still using it under Windows and under Linux (with
Wine).
James Van Buskirk
> > I was trying to
> > do essentially "Hello, world" in OpenGL and I kept my attempt
> > under 10 kLOC and it almost works, but I stayed up most of
> > last night and there is one subtle point that seems to keep
> > it from working. What do you do when you have a problem like
> > this? Nobody that does graphics or Windows can do anything
> > with the program because it's in Fortran, and nobody that
> > does Fortran can help because it's Windows specific. I've
> > gone over the documentation for Fortran, Windows, and OpenGL
> > and printed out all the function results to a file and they're
> > the same when the program works correctly and when it doesn't.
> > I am just stumped.
> I tried five years ago OpenGL but I do not remember if I succeeded.
> Anyway it seems that you can not have true child windows within an
> OpenGL window. It is not a window manager.
I finally got my "Hello, world" program to work.
http://home.comcast.net/~kmbtib/Fortran_stuff/example2.zip
It even comes with an executable in case it proves too difficult
to compile. Turns out that if you're a newbie at both Windows and
OpenGL programming there is a just an awful lot of stuff you've
got to learn before you can get started.
Jerry DeLisle
I too am interested in the GTK+ interface triggered by Tobias' post. What
progress have you made? Perhaps we can collaborate?
Jerry
Hani Ibrahim
> On 12/29/2010 03:50 AM, vincenzo wrote:
> I too am interested in the GTK+ interface triggered by Tobias' post.
> What progress have you made? Perhaps we can collaborate?
There is/was a approach to write a more or less complete Fortran
interface for GTK+, called PILIB. But development stopped a long time
ago. Mabe it still fits your needs:
http://pilib.beta-centauri.de/index.php?title=Main_Page
or you can develop it further. It does not use C-bindings, so it work
with a pure Fortran 90 compiler.
Regards, Hani
vincenzo
> I too am interested in the GTK+ interface triggered by Tobias' post. What
> progress have you made? Perhaps we can collaborate?
yes I would be very happy to collaborate on that subject. I am not a
professional developer, but just a Fortran user with skills in
numerical algorithms. I made some Java some years ago and I am now
learning Python. But I have never really used C language (I need to
revise...)
I succeeded compiling and running Tobias program (I named it gtk2.f90)
under Linux and Windows. This is how I proceeded:
Linux (Ubuntu 10.10):
Install gfortran and the GTK2 development files (headers and static
libraries):
sudo apt-get install gfortran libgtk2.0-dev
Compilation and linking:
gfortran gtk2.f90 -lgtk-x11-2.0
Execution:
./a.out
Windows (Windows XP):
Install the GIMP.
Install MinGW (Minimalist GNU for Windows) using the Automated MinGW
Installer:
http://www.mingw.org/wiki/Getting_Started
Select fortran (and possibly c++ and MSYS).
Add C:\MinGW\bin; to the PATH environment variable
The GTK2 library is in C:\Program Files\GIMP-2.0\bin\
Problem with gfortran gtk2.f90 -L”C:\Program Files\GIMP-2.0\bin\” -
llibgtk-win32-2.0-0
Temporary solution: place the gtk2.f90 file within that directory.
Compilation:
gfortran gtk2.f90 -L. -llibgtk-win32-2.0-0
Execution:
a.exe
This is only an empty window but I think it is remarkable to obtain it
under Windows and Linux without changing anything in the Fortran
program and without using any line of C language. If we could succeed
drawing some coloured pixels in this windows, it would be a great
progress. We could then draw a Mandelbrot Set to measure the slowing
due to the graphical instructions and compared it for example with
Quickwin or JAPI.
I have made some research about GTK. It seems that in GTK+ 2, we need
the GDK library to make drawing:
http://php-gtk.eu/en/gdkgc-drawing-at-the-pixel-level
But in GTK+ 3, GDK will be replaced by Cairo which is a vectorial
drawing library:
http://live.gnome.org/GnomeGoals/GDKtoCairo
And it seems not straightforward to draw pixels with a vectorial
tool...
Martin Hierholzer's Pilib library could also help us:
http://pilib.beta-centauri.de/index.php?title=Main_Page
This library allow to use GTK+ with Fortran 90 but Martin wrote his
own functions in C language, so his functions can be easily interfaced
with Fortran. My hope is that the ISO_C_BINDING functionnality of
Fortran 2003 could allow us to do the same thing in pure Fortran.
I have also identified a french developer who has worked in 2008 on
the subject:
http://www.developpez.net/forums/d568963/general-developpement/programmation-linux/gtk/gtkp/calcul-intensif-interface/
Best regards
Vincent
David Thompson
<not_...@comcast.net> wrote:
> > > G_CONST_RETURN gchar *gtk_about_dialog_get_program_name(GtkAboutDialog
> > > *about);
> > > void gtk_about_dialog_set_program_name(GtkAboutDialog
> > > *about,const gchar *name);
>
> The example I gave above shows two procedures with the same name,
> one of which is a subroutine and the other a function. There
> must be some kind of name mangling going on so the linker can
> tell them apart.
>
Eh? get != set.
James Van Buskirk
news:nv1gi6labaib9raom...@4ax.com...
> Eh? get != set.
Oops. Didn't properly distinguish between
blahblahblahblah and blahblahblahblah
vs.
blahblahgetblahblah and blahblahsetblahblah
so it's not so impossible after all. Even so, GTK+ had a boatload of
*.h files to convert and it depends on 5 or so brand-X packages which
may or may not need Fortran interfaces for GTK+ itself to be useful.
I have been investing my time in improving my interface to OpenGL.
Now I have better translations of gl.h and glu.h than I did before
and my current example,
http://home.comcast.net/~kmbtib/Fortran_stuff/example3.zip
now has some 3-d effects and text. Also a *.jpeg screenshot for
those of you who can't run the 32-bit Windows executable.
vincenzo
> "David Thompson" <dave.thomps...@verizon.net> wrote in message
> > Eh? get != set.
Good remark ! I had not seen it.
> so it's not so impossible after all.
Yes, it is possible. Jerry DeLisle and me are working on it. By now,
Jerry has successfully writen a Fortran 2003 application with three
buttons in a GTK window that is printing something in the console when
you click them. And I wrote a program which is drawing a mandelbrot
set in a GTK window. We will post more when we have made enough
progress. If you are interested to collaborate, tell us.
> Even so, GTK+ had a boatload of
> *.h files to convert and it depends on 5 or so brand-X packages which
> may or may not need Fortran interfaces for GTK+ itself to be useful.
Of course it needs a lot of work like your OpenGL interface did. GTK+
has thousands of functions but we will implement only those that we
really need. For example, to draw a Mandelbrot set in a window I used
only ten GTK functions.
The main difficulties are:
- learning ISO_C_BINDING and particularly how to pass C pointers,
- learning GTK+ which is a huge toolkit, browsing the official
documentation, tutorials, the .h header files... In order to progress
faster I just ordered the book "Foundations of GTK+ Development", by
Andrew Krause, 2007.
Vincent