[Cairo] Suggestion for replacing cairo_copy with set_gstate.

[Carl Worth]

On Sep 26, Keith Packard wrote:
 > If we care about the more persistent status, then obviously we should 
 > encourage applications to use fewer cairo_t objects in a single
 > context.

I think the persistent status is an important feature, (which reminds
me I was planning to send a message to advertise this feature better).

 > If we prefer a simpler API, then eliminating the duplicate mechanisms of 
 > save/restore copy/destroy seems like the better plan.  I've never been a 
 > huge fan of duplication like this.
 > 
 > I don't know which is the better choice here.

Can't we really do both? The proposal was to maintain the stack, but
expose the cairo_gstate_t object with a couple of new functions to
manipulate the gstate on the top of the stack:

	cairo_gstate_t *
	cairo_get_gstate (cairo_t *cr);

	void
	cairo_set_gstate (cairo_t *cr, cairo_gstate_t *gstate);

And with those functions in place the confusing cairo_copy becomes
redundant and we can drop it.

That would allow us to maintain the stack and persistent status. And I
don't see save/restore set_gstate/get_state as redundant, (PostScript
provides the same).

The biggest drawback I see to this approach is that Cairo will be
exposing two different state objects, (cairo_t and cairo_gstate_t).  
More objects means more complexity that the user needs to understand
in order to use Cairo. But I'm willing to accept that to reduce the
problems with cairo_copy.

-Carl