On 2009-10-05 12:44+0200 Zorg 421 wrote: > On Sun, Oct 4, 2009 at 7:37 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> > wrote: >> On 2009-10-04 08:52+0200 Zorg 421 wrote: >>> the cairo driver of plplot implies it's using X11, which is not >>> necesseraly the case on the mac, more and more it's using quartz >>> natively. >> >> I agree with you (since Quartz is mentioned as a possible back-end for >> cairo) that programming an additional quartzcairo device would be desirable >> for the OS X case. It should also be straightforward; just follow the notes >> in drivers/README.drivers (just updated as of revision 10512) that list >> required changes for a new device. In general, the process is completely >> straightforward for everything other than the actual device code, but in >> this particular case that should be straightforward as well: edit >> drivers/cairo.c to duplicate what is done for xcairo for a new quartzcairo >> device except to change the calls to libpango/libcairo appropriately for the >> Quartz backend. > > Maybe is't better, if the changes appears to be two includes like > > #include <cairo-quartz.h> > #include <gdkquartz.h> > > instead of > > #include <cairo-xlib.h> > #include <gdkx.h> > > It's from memory, but there was a time for wich changes to lablgtk2 > was a simple as this.
Apparently not any longer. In addition to different headers, you also need different initialization calls for X versus Quartz versus WIN32 see http://cairographics.org/manual/cairo-xlib-surface.html versus http://cairographics.org/manual/cairo-quartz-surface.html versus http://cairographics.org/manual/cairo-win32-surface.html. Those URL's lead to questions for Hazen (our cairo maintainer). Hi Hazen: Would you be willing to implement access to the quartz and win32 backends in cairo.c? I think there is a case for having both xcairo and (say) quartzcairo devices simultanously accessible on OS X (rather than just one or the other) and similarly xcairo and (say) win32cairo devices on Windows environments with access to X (e.g., Cygwin) in order to facilitate comparisons between those different interactive backends. However, if you prefer just one (possibly renamed) interactive device with conditional coding to facilitate which X, or Quartz, or WIN32 backend is used for that one interactive device, that approach is fine as well with me. I don't want to dismiss how much work would be involved (especially the testing on the OS X and windows platforms accessible to you), but the project does look completely straightforward. I assume the largest difference between access to the X, Quartz, and WIN32 backends would be the use of the cairo_quartz_surface_create call or cairo_win32_surface_create call instead of the cairo_xlib_surface_create call (currently in xcairo_init_cairo). Obviously, different headers would be required as well for each backend. The above URL's lead to a slightly different but still related topic. The cairographics library stack defines a macro for each backend depending on whether that backend is available, i.e., CAIRO_HAS_XLIB_SURFACE, CAIRO_HAS_QUARTZ_SURFACE, and CAIRO_HAS_WIN32_SURFACE. I think we should put in the appropriate tests for whether those macros are defined in cmake/modules/cairo.cmake, and adjust PLD_xcairo, PLD_quartzcairo and PLD_win32cairo (if you decide to use separate devices) accordingly. I am thinking along the lines of using the CHECK_C_SOURCE_RUNS CMake macro with some simple source code that returns success (0) or failure (non-zero) depending on whether, e.g., CAIRO_HAS_XLIB_SURFACE is #defined or not. I would certainly be willing to help set up such tests, and actually make sure the test worked in the X case. Such an X backend test would have solved the original poster's issue with xcairo in an environment where CAIRO_HAS_XLIB_SURFACE would not have been #defined. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
