> > The patch below (against svn rev 8364) addresses this by moving the
> > definition of PLXcairoDrawableInfo from drivers/cairo.c into
> > include/plplot.h. It is still protected by the PLD_xcairo so at least in
> > theory its presence should not cause any trouble when plplot is compiled on
> > a system without X windows. However, I do not profess to be an expert in
> > this area so I'll defer to the judgement of others. Is this a reasonable
> > solution to the problem?
> >
> > Even if this particular solution is not adopted I think we need to come up
> > with some way of making PLXcairoDrawableInfo visible to users.
>
> Here's the proposed code to be added to plplot.h:
>
> > +/*
> > + * Structure for passing external drawables to xcairo devices via
> > + * the PLESC_DEVINIT escape function.
> > + */
> > +#if defined(PLD_xcairo)
> > +#include <X11/X.h>
> > +#include <X11/Xlib.h>
> > +typedef struct {
> > + Display *display;
> > + Drawable drawable;
> > +} PLXcairoDrawableInfo;
> > +#endif
>
> We've managed to keep X11 and other driver-specific headers out of plplot.h
> for a long time, and I hesitate to start now.
I guessed this to be the case.
> Although a particular plplot distribution may have PLD_xcairo defined,
> that doesn't mean the user has any need for it. In which case you are
> sucking in a lot of unnecessary stuff to all user code that includes
> plplot.h.
True, although whether it makes any practical impact on compilation speed
these days is a matter of discussion.
> So I'd prefer an alternate solution, something along the lines of one of:
>
> 1. Given that this kind of capability may be useful and/or desired for more
> than one driver, generalize the concept. The pointer could be a (void *),
> easy enough. The Drawable on my system resolves to:
>
> X.h:typedef XID Drawable;
> Xdefs.h:typedef unsigned long XID;
>
> so an unsigned long would do the trick. Then cast accordingly in the
> driver.
>
> This approach has been generally followed in the past with colors, input
> events, event handlers, etc. But it can be tricky.
I guess I'm not comfortable with the idea that we can always assume the type
of Drawable unless the X11 "standard" says that it is. For example, is it
still "unsigned long" on 64 bit architectures?
I guess the other disadvantage of this more generic solution is that one
looses the static type checking we have if the X types are used directly.
> 2. Give up on the idea of genericity for everything and go with a separate
> X-windows specific plplot include file, e.g. plplotX.h. This is tempting
> since you could add as many convenient definitions as you wished. I've
> almost done this on several occasions. But resisted the temptation since
> I thought the generic solution was a better way to go, when practical.
I'm all for generic solutions, especially when the different cases are
almost degenerate. In that case it makes maintenance somewhat easier. I
haven't had a close enough look at the plplot headers to know how much
degeneracy would be in platform/driver-specific header files. My gut
feeling is that doing the separation because of the PLXcairoDrawableInfo
is probably overkill.
> Just thought of:
>
> 3. Leave it inside the plplot.h header, but only activated if PLD_xcairo AND
> some user-defined macro were defined. Something like PL_activate_X_headers,
> or whatever. That way it's always off by default.
I could probably live with this although to me it still seems a bit
suboptimal. If nothing else it introduces an obscure define which users
must know about if any of this is to work. Of course if it's clearly
documented (preferably in the manual and in example code) this wouldn't be
as bad. At least today I prefer option 3 to either 1 or 2. :-)
Regards
jonathan
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
