[cairo] Redoing the xlib surface constructors

[Carl Worth]

On Fri, 11 Mar 2005 16:30:46 -0500, Owen Taylor wrote:
> What we have currently is:
[...]
> Problems:
[...]

Owen, thanks for the cogent background summary, as usual.

> The attached patch reworks that to:
>
> cairo_xlib_surface_create_for_pixmap
> cairo_xlib_surface_create_for_pixmap_with_visual
> cairo_xlib_surface_create_for_window_with_visual
> cairo_xlib_surface_set_size

I'm quite happy with those four functions as proposed:

> One possible extension here is to reuse the cairo_xlib_surface_create()
> name for creating a pixmap and surface at the same time in a standard
> format:

Yes, I was hoping we could have this. But that's probably just because
I'm lazy.

> cairo_surface_t *
> cairo_xlib_surface_create (Display        *dpy,
>                            Drawable       *drawable,
>                            int             width,
>                            int             height,
>                            cairo_format_t  format);
> 
> (You have to pass a drawable in here because XCreatePixmap needs
> it for the screen. Or we could pass a screen number instead, which
> would make the prototype a little less confusing.)

Oh, bummer. The Drawable argument is both confusing, and chips away at
some of the convenience here. Could we do something lame and just make
it use the default screen, (since convenience functions need not be
perfectly general) ?

> I don't know what to do for the planned 
> 
>  cairo_t *cairo_create_for_* 

Yeah, I'm still trying to think of a good solution here.

>  cairo_create_for_xlib_pixmap_with_visual()
> seems pretty excessive, for something (using Xlib) which is already
> pretty darn verbose. Maybe just skip them?

Skip them in general, or just for Xlib?

The problem that the cairo_create_* convenience functions are trying
to address is the pain of manual object management. Without them, the
user must manage two objects, (a cairo_t and a cairo_surface_t), and I
really want to have things like the tutorial full of single-object
drawing code.

As for the argument that Xlib is nasty-verbose anyway, don't forget
that Keith came up with a working cairo-xlib-using program that fits
(readably!) on a single slide.

If we can pull off cairo_xlib_surface_create, then we can have a
pretty succinct cairo_create_for_xlib. It wouldn't be hard for you to
convince me that there would be little benefit to actual harm in also
adding the rest of the possible cairo_create_for_xlib_* functions.

> The attached patch seems to work pretty well in testing. Patch
> comments:

The patch looks very good to me. Please feel free to commit this. (I
had been hoping for a long time that someone much more Xlib-clueful
than myself would come along and fix my nightmarish gaffes in
cairo_xlib_surface.c.)

-Carl

PS. And just to demonstrate that lack of clue again, we really will
need colormap, right? I know you explained why to me before, but I've
forgotten again, and I still see it being ignored in the code. (I'm
not actually questioning its place in the API, just curious to be
reminded what it is I keep forgetting.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050311/2f671858/attachment.pgp