Graphics status

[jtappin]

Since several of us appear to be looking at different aspects of Gtk-Gdk-Cairo graphics, I've started this issue as a place to note ideas and progress.

[jtappin]

Event handling

I've now got a set of gdk event structures successfully extracted for both Gdk 2 & Gdk 3, though I've only tested it with 3.0 so far.

I have been able to modify cairo-basics.f90 to report the details of mouse clicks and wheel scrolls, I'll also try to make a version of mandelbrot-pixbuf.f90 with zooming. Once I've got the stuff checked out on Gtk2 as well, I'll commit the events list and the examples (provided no-one has profound objections to adding a perl script to the tools).

[jerryd]

On 05/20/2011 10:40 AM, jtappin wrote:

Since several of us appear to be looking at different aspects of Gtk-Gdk-Cairo graphics, I've started this issue as a place to note ideas and progress.

Very good. I have been so busy on gfortran bugs, I have not been able to focus
here. I appreciate all your support.

[jtappin]

I've now committed the gdk events structures (there is one in Gtk2 that isn't interoperable since it contains a union -- but since that one isn't even in Gtk3 I doubt is matters overmuch), and 2 demo codes

• cairo-basics-click.f90: A rather trivial modification of cairo-basics.f90 that just prints out details of mouse clicks and wheel events.
• mandelbrot_pixbuf_zoom.f90: A modified version of mandelbrot_pixbuf.f90 that allows the user to zoom in on regions with mouse clicks and wheel events.

Both are built by the cmake build system, and are in both master and gtk3 branches.

[bonanza]

I think, there is a big need for fast high level 2D/3D plot routines.
There are several options:

1. GtkExtra (http://gtkextra.sourceforge.net/):
   • have been tested, but not really successful (GtkExtra installation problem #11)
   • new version 3.0.1 have been published on May 01, 2011 --> should be tested
2. GtkDatabox (http://sourceforge.net/projects/gtkdatabox/)
   • GtkDatabox is a widget for live display of large amounts of fluctuating numerical data. Data presentation (e.g. on linear or logarithmic scales, as dots or lines, with markers/labels) as well as user interaction (e.g. measuring distances) is easy.
3. GtkPlot (https://github.com/pchilds/GtkPlot):
   • Plot builds upon GtkDrawingArea. It compiles & works under gtk+2. As drawing is performed using cairo graphics, upgrading to be compatible with gtk+3 in the near future should be trivial.
4. in-house development (see hornekyle's comment in CMake Build System #23)

[jtappin]

I'd add a Fifth option:

• Make a high-level graphics window system that interfaces easily to any library that can write to a pre-existing drawable. The plplot library (http://plplot.sourceforge.net/) has such a capability (and also a well-developed Fortran 95 interface) and could be used as a specimen.
  The biggest issue (that I can see) is that the Cairo-Gtk/Gdk example is rather old and uses many deprecated Gdk functions. I think we would need to push some interfaces to some low-level routines to upstream as they are currently C-only.

[jtappin]

I've now managed to produce a high-level drawing interface (not high-level drawing, just high-level interface) that manages redrawing automatically. There are still a few rough edges to clean up and also endianess invariance to check (the C example code that I used (http://www.gtkforums.com/viewtopic.php?f=3&t=5204&p=70019#p70019) shows that cairo_surfaces and gdk_pixbufs have different behaviour in this area.

The code will provide:

1. A high-level interface to create a drawing area and to connect event handlers, and creates a backing pixbuf.
2. A default expose event / draw signal handler that regenerates the drawing area from the pixbuf
3. A pair of routines to create a cairo context that is linked to the pixbuf and to update the pixbuf and destroy the context (these would be placed around your drawing code).

Currently the source file is gtk-draw-hl.f90 and the generated module gtk_draw_hl -- I've kept it separate from the main gtk_hl as many codes using gtk_hl won't need the graphics.

[jtappin]

I've now committed the high level draw interface to both branches.

[jtappin]

PLplot

I have now managed to get one of the example codes from the plplot f95 examples set to send its output to a gtk drawable created by the gtk_draw_hl routines. The process can be summarized as:

• Create a drawable without transparency, with a backing store pixbuf and the default expose/draw callback.
• Open plplot with the memcairo device
• Set the memory to the pixbuf's pixels
• Draw, then send a draw signal.

This may not be the best way, but it works.

There are however a few problems for a production system:

• On most Linux distros the plplot f95 bindings are built with gfortran 4.5 or lower (Arch may be an exception) so you need to build your own plplot as the .mod files are incompatible between releases.
• Using the snapshots (at least on 64 bit systems), the plplot C++ bindings will not build and I could not persuade it not to try building them (I did set the option to build C++ to NO, but it still tried some C++ stuff and failed).

Right now I've only got it running on the iBook as that's the only machine I have with a packaged gfortran 4.6 (I'll give the 32-bit box a shot later). Also I've not even started to figure out plplot's cmake stuff.

[vmagnin]

James, I missed that episode... I have just successfully build your plplot examples (master branch). It is really amazing ! (Especially example 8.)
This is a great added value for gtk-fortran. Perhaps you could add a wiki page with some screenshots...

[jtappin]

I think that now that most distros have gfortran 4.6 or 4.7, it might be possible to make the plplot stuff into an optional part of the main build.

[vmagnin]

yes, the plplot stuff is an important brick for people that might be interested by gtk-fortran. Not only they could create a GUI and plot bitmaps, but also plot many kinds of scientific curves.

[jtappin]

I'll look into it -- as I said I think it needs to be optional as we don't want to make the core dependent on plplot. I found a cmake file for plplot in GDL -- it's GPL2+ licensed so I think we can use that.

I think that the gtk-extra option is pretty much moribund. I think it was about a year ago that I contacted the lead author to ask if there were any plans for a GTK+3 version and he said it would be out by the end of the year (2011) [IIRC].

[bonanza]

Let's give the GtkExtra guys some more time. Afaics there are still efforts to migrate to GTK+3 (http://gtkextra.cvs.sourceforge.net/viewvc/gtkextra/gtkextra-3/ChangeLog?sortby=date&view=log) - but things are going forward really slowly and it's still in "preparation". However, imho we should concentrate on plplot at the moment.

[vmagnin]

Right, gtk-fortran should not depend on PLplot.

The PLplot project seems to be regularly active, with at least two releases by year since 2001. And it is packaged in .deb and .rpm. So I think it is a good choice. (And more, you showed it works with gtk-fortran !)

[jtappin]

I've now got an automatic detection of plplot working on Ubuntu 12.04 (so that it builds the interface module and the examples if plplot is found, and not it it isn't).

Since the search for the plplot modules is not very automated (I have to give a list of directories to try), I need to check it on a few more distros before I commit & push the changes.

[vmagnin]

Fine.
Concerning searching plplot, I think to the whereis plplot command to test if plplot is installed. A locate plplot command could be used to obtain the location and list of all the plplot files. It is a UNIX command, so it should theoretically work on any distro.

[jtappin]

For cmake the magic tool is the FindPkgConfig.cmake file which allows cmake to use include directories etc. from pkg-config.