Alan W. Irwin wrote: > 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.
My recollection is that these backends were considered experimental, or at least they were back when I used to monitor the cairo mailing list? Assuming that this is no longer the case then it seems reasonable to support them. However, I foresee some pain in interfacing with Quartz / win32 to create a window, handle its events, etc. On OS-X this is probably going to involve rolling some Objective-C into the driver. -Hazen ------------------------------------------------------------------------------ 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
