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
>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.
> 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).
> 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
On 27 déc, 22:37, Wolfgang Kilian <see...@domain.invalid> wrote:
> 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.
Thank you James for this answer. 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.
> On 27 déc, 21:27, "James Van Buskirk" <not_va...@comcast.net> wrote: > > 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); > Thank you James for this answer. > 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.
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.
-- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
> 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.
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).
> > 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.
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.
-- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
> On 27 déc, 22:37, Wolfgang Kilian<see...@domain.invalid> wrote:
>> 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
I too am interested in the GTK+ interface triggered by Tobias' post. What progress have you made? Perhaps we can collaborate?
> 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:
On Jan 1, 7:29 pm, Jerry DeLisle <jvdeli...@verizon.net> wrote:
> 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.
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.
> 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.
> On Wed, 29 Dec 2010 11:57:05 -0700, "James Van Buskirk" > <not_va...@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.
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,
On 11 jan, 11:30, "James Van Buskirk" <not_va...@comcast.net> wrote:
> "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.
