[cairo] Re-working cairo_current_path

[Kristian Høgsberg]

Carl Worth wrote:
> 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.

Cool, I've got a couple of changes here that I'll commit - better bbox 
computation so I don't clip the spikes plus a nice blue gradient for the 
letters.  Oh, and I added a few lines of code to optionally parse the 
QUERY_STRING environment variable:

	http://bitplanet.net/kapow.cgi?text=CAIRO

>>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."

Will a nickle buy you a real language?  Closures or not, I think the 
thing about setting a 'first' flag is still messy.

> 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 ?

Well, fill and stroke also consume the path, so it's not completely 
irregular--maybe cairo_walk_path()?

cheers,
Kristian