[cairo] Re-working cairo_current_path (was: New little cairo demo)

[Carl Worth]

On Sun, 23 Jan 2005 01:35:10 -0500, Kristian Høgsberg wrote:
> I was playing around with cairo and came up with this little example.  I 
> though it might be interesting to add to cairo-demos or something.

Hey, that's really cute. I've got biff.png, bang.png, and pow.png
here ready for my next great American graphic novel. I've also added
this to cairo-demo/kapow.

> I was wondering, though, about the cairo_current_path() and 
> cairo_current_path_flat() functions.  Don't you typically want to start 
> a new path when you call these functions?  What I'm doing in this 
> example is to call cairo_new_path() in the first callback and then set a 
> flag in the closure.

I found myself doing the same thing, and it is annoying.

When I mentioned this to Keith, his reaction was something like,
"Here's a nickle, kid. Get yourself a language with real closures."

But the pain in C of having to create a new struct really is awful.

>                  My gut feeling is that the "call new_path and set a 
> flag" will be a common pattern with this interface and could be avoided 
> with a little tweaking.

I think that both the "replace path" and "leave path untouched" usages
of cairo_current_path are quite legitimate, and I won't hazard a guess
as to which is more common.

But it does occur to me that with "destroy path" the pain of using it
the "other" way will be reduced. Notice that restoring the path in
that case could work with just the cairo_t* as the closure argument,
(no gratuitous struct is necessary for the extra flag). So, at worst,
the pain is that the user must fill out stubs for every function.

This also means that a needless path copy will be eliminated in the
"replace path" usage.

So I'm convinced to switch the default unless anyone comes up with a
compelling reason not too.

The only thing I find a bit distasteful is that after calling
cairo_current_path that path won't be the "current" one anymore, so
we've made a lie out of the name. It also works quite differently from
any other "current" function, so a different name would be
suitable. Perhaps cairo_query_path ?

Oh, but then Keith also has a separate plan for modifying
cairo_current_path to return an exposed cairo_path_t, (likely not the
same structure as what we're currently using internally). That would
eliminate the callbacks and this current issue entirely.

Keith, what was your proposed data structure for the path? A list of
double with magic values to specify each operator?

-Carl
-------------- 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/20050124/a6127dc9/attachment.pgp