gtkmm, cairo, and XLib

[Jonathon Jongsma <jonathon jongsma gmail com>]

I sent the attached message to the cairo mailing list a couple of
weeks ago because it was an issue that was affecting the cairomm
bindings when enabling support for XLib surfaces.  We decided to
rename the Cairo type from Cairo::Status to Cairo::ErrorStatus to
sidestep the issue.

Well, now the issue is popping up in gtkmm.  It turns out that if your
cairo library is compiled with xlib surface support and you want to do
any cairo drawing in gtkmm (i.e. by including <cairomm/context.h> or
similar), you won't be able to compile your application.  In
particular, I'm running into this issue in the
examples/book/drawingarea/clock/clock.cc file.  The specific issues
I've found so far:

1) Gdk::Status (suffers from the same issue noted below -- Status gets
replaced with int because of a '#define Status int' line in Xlib.h)

2) <glibmm/object.h> line 118 is as follows:
  typedef void (*DestroyNotify) (gpointer data);
  void set_data(const Quark &key, void* data, DestroyNotify notify);

Xlib.h includes X.h, which contains the following line:
#define DestroyNotify       17

So we're trying to use DestroyNotify as a type name, but this simply
gets replaced with a constant integer by the preprocessor (depending
on the include order), despite the fact that it's in the Glib
namespace and only defined within the Object class.

The problem, of course, is that these types are part of the public API
which is supposed to be stable, so we can't easily work around the
problem the way we did in cairomm.

Anybody have any thoughts?

Jonner


---------- Forwarded message ----------
From: Jonathon Jongsma <jonathon jongsma gmail com>
Date: Jan 12, 2006 8:41 AM
Subject: CAIROMM: Status type and Xlib
To: cairo cairographics org


In experimenting with implementing a heirarchy of surfaces in cairomm,
I've run across a problem that took me a while to track down.  cairomm
typedefs cairo_status_t as Cairo::Status.  This was working fine until
I added support for XlibSurface, which needs to pull in a bunch of
xlib headers.  The problem is that Xlib.h contains the line:

#define Status int

So any Status type that occurs after Xlib.h is included gets replaced
by the preprocessor with 'int'.  I don't know why it's a #define
instead of a typedef.  If it was a typedef, it would work fine since
Cairo's Status type is declared within the Cairo namespace.  But
obviously the preprocessor is not namespace aware so it simply
replaces it wherever it exists.  This creates a bunch of linking
problems because in some files the Status type gets treated as an int
and in some files it gets treated as a cairo_status_t.

The obvious solution to this issue is to rename the Status type in
cairomm, but it's slightly annoying that we have to worry about this
at all (since it's defined within a namespace precisely to avoid these
sorts of naming conflicts).  Is there any other way to work around
this?  Or any ideas for a new name?

Jonner