Re: gtkmm, cairo, and XLib

[Murray Cumming <murrayc murrayc com>]

On Mon, 2006-01-23 at 23:25 -0800, halbtaxabo-debml yahoo com wrote:
> #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.

I agree. I had meant to suggest that to Jim Gettys when we discussed
this on the cairo list.

If we can't get that fixed then we may have to hide the cairo headers from the cairomm headers. We probably want to do that anyway.

> --- 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
> > 
> 
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com