Just my 2p - I'm with Maurice in prefering to keep driver specific features out of plplot.h . A generic solution is more the plplot way of doing things - or failing that a separate driver specific header.
Andrew On Mon, Apr 14, 2008 at 05:39:04AM -0000, [EMAIL PROTECTED] wrote: > 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 > ------------------------------------------------------------------------- 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