Re: [Plplot-devel] plplot, cairo on OSX without X11 libs
On 2009-10-05 15:27-0400 Hazen Babcock wrote: > Alan W. Irwin wrote: >> 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. I am glad you agree with me about supporting these backends. I believe we can assume they are mature by now from the following quote from http://cairographics.org/: "Cairo is a 2D graphics library with support for multiple output devices. Currently supported output targets include the X Window System, Quartz, Win32, image buffers, PostScript, PDF, and SVG file output. Experimental backends include OpenGL (through glitz), XCB, BeOS, OS/2, and DirectFB." That is, Quartz and Win32 are included in the list of backends we already support with essentially no issues, and they are not included in the list of experimental backends at the end of that paragraph. 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
Re: [Plplot-devel] plplot, cairo on OSX without X11 libs
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 >> 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 >> #include >> >> instead of >> >> #include >> #include >> >> 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
Re: [Plplot-devel] plplot, cairo on OSX without X11 libs
On 2009-10-05 12:44+0200 Zorg 421 wrote: > On Sun, Oct 4, 2009 at 7:37 PM, Alan W. Irwin > 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 > #include > > instead of > > #include > #include > > 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
Re: [Plplot-devel] plcairo in latest SVN
On Mon, Oct 5, 2009 at 5:31 AM, Zorg 421 wrote:
> Hello plplot developpers,
> Since Sept29 the build system for plcairo has been integrated into cmake.
> Unfortunately, on my godi 3.11 on a mac, with ocaml-cairo from GIT and
> lablgtk2 from svn installed by hands in
> site-lib and std-lib respectively, it's not beeing detected by cmake
> configuration:
>
> ...
> -- OCAMLC = /opt/godi311/bin/ocamlc.opt
> -- CAMLIDL = /opt/godi311/bin/camlidl
> -- OCAMLMKLIB = /opt/godi311/bin/ocamlmklib
> -- OCAMLOPT = /opt/godi311/bin/ocamlopt.opt
> -- OCAMLFIND = /opt/godi311/bin/ocamlfind
> -- OCAML_LIB_PATH = /opt/godi311/lib/ocaml/std-lib
> -- CAMLIDL_LIB_DIR = /opt/godi311/lib/ocaml/std-lib
> -- WARNING:Cairo OCaml library not found. Disabling Plcairo module
> -- WARNING: lablgtk2 OCaml library not found.
> ...
>
>
> While:
>
> $ ocamlfind query plplot
> /opt/godi311/lib/ocaml/site-lib/plplot
>
> $ ocamlfind query cairo
> /opt/godi311/lib/ocaml/site-lib/cairo
>
> and ls /opt/godi311/lib/ocaml/std-lib/lablgtk2/ gives 273 dir entries.
> I guess lablgtk2 is reachable using "ocamlopt -I +lablgtk2".
>
> Is there some define option to the cmake configure to set those paths
> for bypassing autodetection?
The Plcairo module is very young and still prone to changes in both
its build requirements and API, at least until the next PLplot
release. Thank you for your testing and reports in the mean time.
As of now, ocamlfind support is required for Cairo-OCaml in order for
the Plcairo module to be built. ocamlfind support for lablgtk2 is
only required to build the example examples/ocaml/xgtk_interface.ml
which uses the Plcairo module.
That explains why CMake does not find your lablgtk2 installation. I'm
not sure why the CMake configuration process is not finding your Cairo
OCaml install. It tests for Cairo OCaml by attempting to compile a
one line program:
module C = Cairo
using this compilation line:
${OCAMLFIND} c -package cairo -linkpkg \
test_cairo.ml -o test_cairo
If the compilation fails then the Plcairo module is disabled. A
similar test is made for Gtk, but in this case both the Gtk and
Cairo_lablgtk modules are checked:
module G = Gtk
module C = Cairo_lablgtk
compiled with:
${OCAMLFIND} c -package cairo.lablgtk2 -linkpkg test_gtk.ml -o test_gtk
If that OR the Cairo OCaml check fails then the xgtk_interface.ml
example is not built.
Could you test these and report back the results? Additionally, could
you send me the complete output from cmake as well as the complete
output from make when you build PLplot as attachments off-list?
Thank you for taking the time to test and report these issues.
Hez
--
Hezekiah M. Carty
Graduate Research Assistant
University of Maryland
Department of Atmospheric and Oceanic 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
Re: [Plplot-devel] plplot, cairo on OSX without X11 libs
On Sun, Oct 4, 2009 at 7:37 PM, Alan W. Irwin wrote: > On 2009-10-04 08:52+0200 Zorg 421 wrote: > >> Hello plplot developper, >> >> I've built a plplot trying to link it only against a Cairo/Glib/Gtk >> framework which use >> directly quartz and bypass, know nothing about X11. >> It failed with the following error: [...] >> I've inverted some paths in PKG_CONFIG_PATH to fall on >> X11 cairo before quartz cairo but it's a bit of a shame. > > Is this a correct summary of what you wrote above? The xcairo device does > not build properly for a cairographics environment that excludes X (for > obvious reasons), but you found an alternative cairographics environment > that does include X which works. Hmm the one environnement on which the build fail is any of the native port of gtk to quartz directly, bypassing the need of the embedded X server of OSX. For example: http://www.gtk-osx.org/ My workaround is to use an X-based libcairo of macports, which implies having the OSX X server active for seeing the plplot example selecting the xcairo driver. > Assuming that summary is correct, does -dev xcairo work at run time for you? > If you feel our wiki at > http://www.miscdebris.net/plplot_wiki/index.php?title=Mac_OSX_Status needs > updating (say by adding the qualifier "cairographics must support X or else > must specify -DPLD_xcairo=OFF") please do so. > >> [out of order] >> 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 #include instead of #include #include It's from memory, but there was a time for wich changes to lablgtk2 was a simple as this. So a -DDARWIN_QUARTZ_ONLY define or something similar would do the trick without duplicating extra code. NB: I haven't yet looked at plplot code, it's from previous experience about quartz vs X building. Regards. > Note, that we are all volunteers here who tend to work on our own PLplot > priorities. So if nobody else here volunteers for the above straightforward > job, I suggest you do it yourself (assuming you have some basic C > knowledge), and send us a patch so that everybody can benefit from your > work. I am sure everybody here would be willing to help you with any > questions you might have about the process of adding a new device to PLplot, > but the first place you should consult is (the newly updated) > drivers/README.drivers. > > Alan > __ > Alan W. Irwin -- 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
[Plplot-devel] plcairo in latest SVN
Hello plplot developpers, Since Sept29 the build system for plcairo has been integrated into cmake. Unfortunately, on my godi 3.11 on a mac, with ocaml-cairo from GIT and lablgtk2 from svn installed by hands in site-lib and std-lib respectively, it's not beeing detected by cmake configuration: ... -- OCAMLC = /opt/godi311/bin/ocamlc.opt -- CAMLIDL = /opt/godi311/bin/camlidl -- OCAMLMKLIB = /opt/godi311/bin/ocamlmklib -- OCAMLOPT = /opt/godi311/bin/ocamlopt.opt -- OCAMLFIND = /opt/godi311/bin/ocamlfind -- OCAML_LIB_PATH = /opt/godi311/lib/ocaml/std-lib -- CAMLIDL_LIB_DIR = /opt/godi311/lib/ocaml/std-lib -- WARNING:Cairo OCaml library not found. Disabling Plcairo module -- WARNING: lablgtk2 OCaml library not found. ... While: $ ocamlfind query plplot /opt/godi311/lib/ocaml/site-lib/plplot $ ocamlfind query cairo /opt/godi311/lib/ocaml/site-lib/cairo and ls /opt/godi311/lib/ocaml/std-lib/lablgtk2/ gives 273 dir entries. I guess lablgtk2 is reachable using "ocamlopt -I +lablgtk2". Is there some define option to the cmake configure to set those paths for bypassing autodetection? Thanks, regards. -- 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
