[Cairo] make error with cvs cairo

[Carl Worth]

On Sep 16, Bill Spitzak wrote:
 > I'm not clear if somebody calling Cairo would need to call or use any symbols 
 > in ic.h. If not, I really recommend that it not be in the public header 
 > files. You can always include it in the source files of Cairo that
 > use it.

Right now there are just some enum values. We can get rid of those,
(in the same way we'll want to get rid of the PictStandard enum values
from Xrender.h).

 > Getting Xlib out of any public header files is extremely important. It 
 > pollutes the namespace with many symbols and typedefs and macros.

It's funny, I've never actually run into any problems with this in my
own code. It must be that I have different natural naming conventions
than those of the Xlib authors.

But I do understand the pain when library headers don't stick to
strict namespace preservation conventions.

 > I would prefer that void* or other standins be used in any
 > structures that have a field for xlib objects.

I don't want to give up typechecking though.

And really, I don't see the point. As I mentioned before, the main
cairo.h header file will not include things like Xlib.h. There will be
a separate cairo-x11.h that has the interfaces that depend on Xlib
datatypes. Presumably, if someone wants to call those functions, then
they are already going to have to include Xlib.h in their own code in
order to get their hands on the data in the first place.

Otherwise, you'll be able to just include cairo-pdf.h or whatever it
is you want to draw to, and ignore the namespace pollution from
the underlying headers of other backends.

 > Sorry I meant XrDouble. I really recommend these be eliminated from Xr as 
 > well.

Heh, I don't think there was ever an XrDouble type either. There
certainly isn't now as there is no Xr anymore, (it was renamed to
Cairo).

You may be thinking of the XDouble type from Xrender.h. If cairo.h
ever had XDouble in its interfaces, that was a bug. Regardless, it's
certainly not there now.

 > > This is now cairo_fixed_16_16_t or cairo_fixed_t. The typedef here is
 > > for internal use by Cairo.
 > 
 > This is of course the typedef that I mis-interpreted because of all the 
 > XrDouble and XrInt and other unnecessary typedefs.
 > 
 > First I would get this out of the headers if it is not needed by outside 
 > users.

As I said before, there are no useless typedefs in the public cairo.h
header. The only things left today are a few opaque structs:

	typedef struct cairo cairo_t;
	typedef struct cairo_surface cairo_surface_t;
	typedef struct cairo_matrix cairo_matrix_t;

and a handful of enum values.

The enum values are currently set to symbolic values obtained from
Xrender.h or ic.h. We can certainly drop those and just map from
CAIRO_FORMAT_ARGB32 to PictStandardARGB32, etc. internally.

After that, we could move the X-related functions to cairo-x11.h.

That would let us drop all #includes from cairo.h except for
fontconfig. To get rid of that, we just need to decide the header file
in which those functions belong. Should the graphics backend imply a
specific text backend? Or does the user want to be able to select both
of those independently?

For ease of use, I'd like the user to be able to specify an entire
backend, (graphics and text), by including a single header file. If
necessary we can make multiple files for different graphics text
backend combinations, (eg. cairo-win32.h and cairo-wind32-ft.h or
whatever).

 > If you want, I can at least get it so that it does not require the xrender 
 > header files to compile a program which calls Cairo, though I doubt I will be 
 > able to get any programs to execute yet. Notice that my solution will assumme 
 > that the declared Cairo triangle and other types are exactly equivalent to 
 > what Xrender declares. Is this ok?

Sure.

The code already makes a bunch of assumptions like this. For example,
it defines its own cairo_trapezoid_t and then just casts it to either
IcTrapezoid or XTrapezoid. And yes, there's a /* XXX: Evil cast */
comment at each occurrence.

-Carl