Re: gtkmm, cairo, and XLib

[<halbtaxabo-debml yahoo com>]

--- Murray Cumming <murrayc murrayc com> wrote:

> On Tue, 2006-01-24 at 09:30 +0100, Murray Cumming
> wrote:
> > 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.
> 
> And here's another one from gtkmm 2.9:
> 
> displaymanager.cc: In function
>
'void<unnamed>::DisplayManager_signal_display_opened_callback(GdkDisplayManager*,
> GdkDisplay*, void*)':
> displaymanager.cc:43: error: 'Display' was not
> declared in this scope
> 
> Adding a typedef makes the problem clear:
> 
> displaymanager.cc:31: error: conflicting declaration
> 'typedef class
> Gdk::Display Display'
> /usr/include/X11/Xlib.h:519: error: 'Display' has a
> previous declaration
> as 'typedef struct _XDisplay Display'
> displaymanager.cc: In function
>
'void<unnamed>::DisplayManager_signal_display_opened_callback(GdkDisplayManager*,
> GdkDisplay*, void*)':

That one's quite different, surely.
It's not a bug in Xlib.h.
Unlike the other cases, you can fix it in Gdk by using
the fully-qualified name, Gdk::Display, instead of
using a typedef to pollute the global namespace.