Thanks Bill, Sounds good for the HAVE_CAIRO vs USE_CAIRO defs, +1. Even if as discussed, it would be very unlikely for 1.3 to have a USE_CAIRO implemented, we should add your comment for future potential use and for make current side effects considerations. Thanks, Fabien
> Here is how it probably should handle Cairo: > > First there is the HAVE_CAIRO configuration option. This indicates that > any cairo calls are available. In this case you get something like this: > > // static variable holding the last cairo context fltk set: > cairo_t* Fl::cr; > > // Make cr draw in this window. This hides the ugly platform-dependent > // part of getting cairo going: > void Fl::cairo_make_current(Fl_Window*) > > // Set cr to something you made yourself. This lets you reuse functions > // that use cr, and also tells fltk that cr is not one of it's own and > // thus cannot be destroyed or reused for a different window: > void Fl::cairo_make_current(cairo_t*) > > Second there is the USE_CAIRO configuration option. This means that all > drawing is done using Cairo. In this case when a widget draw() method is > called, it is exactly as though cairo_make_current(window) has been done. > > Note that it should be possible to compile so HAVE_CAIRO works even if > USE_CAIRO does not, and so that turning on USE_CAIRO does not break any > programs written for HAVE_CAIRO. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
