Ugh.. mailer problems.
On Monday, April 14, 2008 at 14:20:27 (+0930) Jonathan Woithe writes:
> > > 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.
Fair enough, and I doubt it's an issue for me, but it may matter to some. And
from just a design perspective, I'm happier keeping driver specific stuff out
of the main header file. That doesn't mean we need to keep it that way. Life
is
full of compromises. But I'd like to hear some other perspectives.
> > 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?
In my experience of "generalizing" X11 features, I've yet to run into a
problem. In this case, will we ever /really/ encounter a case where the
number of drawables when running plplot exceeds 2^32?
> 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.
Sure, although one could define a generic plplot type that accomplishes
the same thing, with a known mapping to the driver specific types.
> > 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. :-)
Another comment -- in the non-generic approach, instead of
PLXcairoDrawableInfo, just
PLXDrawableInfo
would seem to do the trick. You don't have any cairo-specific data in there,
so the "cairo" part of the name might as well be dropped.
--
Maurice LeBrun
-------------------------------------------------------------------------
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
