Re: gtkmm, cairo, and XLib

[<halbtaxabo-debml yahoo com>]

#define Status int
in Xlib.h, should just be regarded as a bug. It should
be a typedef. (If that causes a problem, well that's
another bug.) The solution is to fix the bug in
Xlib.h.

#define DestroyNotify       17
in X.h is another bug. It should be in an enum, along
with whatever 1-16 (and 18-?) mean in this context.
The solution is to fix X.h.

Once you start tolerating, and working around, poor
coding like this, your problems will never end. What
happens when maintenance to Xlib introduces new
constants? Do you just accept that anything
that uses Xlib can be broken without warning at any
time?

Bite the bullet. Get X.h and Xlib.h fixed, then
announce that the current version of gtkmm depends
on the whatever version of X has the fixes.

--- Jonathon Jongsma <jonathon jongsma gmail com>
wrote:

> 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
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>