Summary: | How do we identify surface types? | ||
---|---|---|---|
Product: | cairo | Reporter: | Steve Chaplin <d74n5pohf9> |
Component: | general | Assignee: | Carl Worth <cworth> |
Status: | RESOLVED FIXED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
Severity: | normal | ||
Priority: | high | CC: | jwatt, murrayc |
Version: | 0.9.3 | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Steve Chaplin
2005-03-18 18:12:54 UTC
Move bugs against "cvs" version to "0.9.3" so we can remove the "cvs" version. This is needed by pycairo, and probably other language bindings in a situation like this: surface = cairo.ImageSurface() # or cairo.PDFSurface(), or cairo.PSSurface(), or cairo.Win32Surface() ... # later we may no longer have the 'surface' reference, and do: surface = cairo.Context.get_target(ctx) # in the get_target() wrapper we need to be able to determine the surface # type so we can create the correct surface object. pycairo now implements Patterns in a class hierarchy (as suggested by the Appendix to the manual) and has the equivalent problem with patterns and the wrapper cairo.Context.get_source() From my point of view (Perl bindings), an enum type typedef enum { CAIRO_SURFACE_TYPE_XLIB, CAIRO_SURFACE_TYPE_PDF, ... } CairoSurfaceType and CairoSurfaceType cairo_surface_get_type (cairo_surface_t *surface) would suffice. (And equivalent stuff for cairo_pattern_t, of course.) Looks like the email archives got renumbered at some point. Here are links to the original thread (though there's not much there that's not already quoted here in this bug): http://lists.freedesktop.org/archives/cairo/2005-March/003431.html http://lists.freedesktop.org/archives/cairo/2005-March/003432.html Looks like the email archives got renumbered at some point. Here are links to the original thread: http://lists.freedesktop.org/archives/cairo/2005-March/003431.html and where it got picked up again a couple months later[*]: http://lists.freedesktop.org/archives/cairo/2005-May/004112.html A single get_type function per object and enums for the return value sounds pretty good to me, (and better than the is_<foo> family of functions I proposed in the thread above). -Carl [*] It is painful beyond annoying that pipermail doesn't do any threading across month boundaries. I'd really like to switch to an archiver that wasn't so broken. This is fixed with the addition of cairo_surface_get_type, (and similarly for patterns with cairo_pattern_get_type, etc.), in cairo 1.1.1 as of 2006-02-28. The relevant commits are below: -Carl PS. It would be a dandy thing to tweak this bugzilla instance so that git commit IDs would automatically be munged into correct gitweb links. commit f9534c856a71b0f56a1e5bc58141b7bc192a27e8 Author: Carl Worth <cworth@cworth.org> Date: Tue Feb 28 01:30:58 2006 -0800 test/pattern-get-type: Add new test case for cairo_pattern_get_type. commit 1dd6e417c10c90894c87565d4f7fa3f63e97f212 Author: Carl Worth <cworth@cworth.org> Date: Tue Feb 28 00:55:27 2006 -0800 Add testing for cairo_surface_get_type. All test targets now list an expected cairo_surface_type_t. Add notes on current limitations of PDF/PS/meta-surface support that causes CAIRO_CONTENT_COLOR similar surfaces of PDF and PS surfaces to be returned as image surfaces. Add cairo_internal_surface_type_t for the meta, paginated, and various test surfaces. commit cd84e2ab32fe4648f9d172cdefe08798336938d2 Author: Carl Worth <cworth@cworth.org> Date: Mon Feb 27 23:15:45 2006 -0800 Add documentation for cairo_font_face_get_type, cairo_scaled_font_get_type, cairo_surface_get_type, and cairo_pattern_get_type. commit 5797f814852bb4f6ef559890640b8cd24ec5fa45 Author: Carl Worth <cworth@cworth.org> Date: Mon Feb 27 23:12:43 2006 -0800 Implement cairo_pattern_get_type commit 5ae0b9f912b7f5fd1700cbf18763a05493f55b62 Author: Carl Worth <cworth@cworth.org> Date: Mon Feb 27 23:11:32 2006 -0800 Implement cairo_surface_get_type |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.