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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
