Why not, I guess?

Where/how do you use it exactly?

I changed logoinsert in -bad to use a GstBuffer property instead of a location= property.  This allows applications to set the property using a binary blob containing a PNG image, while also allowing the old behavior of using gst-launch to load the image from a file.

> I changed logoinsert in -bad to use a GstBuffer property instead of a location=
> property.  This allows applications to set the property using a binary blob
> containing a PNG image, while also allowing the old behavior of using
> gst-launch to load the image from a file.

As I said in our discussion on IRC the other, I think this is awful API. I think the location=localfile.png case is the most common, and I don't see the problem with having a separate "data" property for the buffer data. IIRC you expressed a dislike for having file reading code in elements like this, which I agree with on some level, but we shouldn't invent awkward API to avoid that IMHO.

I would prefer to see this WONTFIXed, and see a plain "location" string property on that overlay element (and additional "data" GstBuffer property if desired).

The IRC log, in case anyone's interested:

04-02-2011:
00:39:21 tim: ds, ew @ logoinsert API ;-)
00:40:49 ds: __tim: got a better solution?
00:41:01 tim: dunno, two separate properties?
00:42:27 ds: how is that better?
00:43:57 tim: Seems simpler and more straight-forward to me, and more discoverable
00:45:28 tim: if you want to insert a logo from file with code, you can't do just g_object_set (logoinsert, "location", "/home/me/logo.jpg", NULL);  any more, can you? But you'd have to create a buffer first, wouldn't you?
00:45:58 tim: and convert the filename into an URI
01:02:39 ds: __tim: yeah, the C code to set the property is definitely clumsier
01:04:02 ds: __tim: i'm not a big fan of elements reading files unless that's their main purpose (like filesrc)
01:04:27 tim: ds, but doesn't that happen with your solution as well?
01:04:50 ds: only from gst-launch
01:05:14 tim: oh, I see, so a C application would need to do the file loading itself
01:05:16 ds: right now, there are several elements that load property information from a file
01:05:19 ds: yeah
01:05:29 ds: which we could wrap with a utility function, but still
01:06:05 ds: If every part of the API requires a utility function to use properly, the API is probably not designed right :)
01:06:29 tim: I think I agree with you in general, but for an element like this it seems a little "popier than the pope" :)
01:08:07 ds: it makes a little more sense for the rsvgoverlay (or whatever it's called)
01:08:09 tim: as a user of such an element, I just want to give it a file name and be done with it (unless I have the data)
01:08:23 ds: where you really might want to create SVG programmatically
01:12:08 tim: ds, not sure I follow. Aren't you arguing that a GstBuffer * argument is really sufficient for logoinsert? But then you say that no one is going to create jpg/png data on the fly [unlike svg data], right? Wouldn't that be an argument in favour of just taking a file location instead?
01:12:29 ds: __tim: er, maybe
01:13:03 ds: __tim: unless you're storing the images in a resource fork, or loading them from http, etc.
01:13:35 tim: right
01:13:46 ds: you *could* save them to a file and then load, but then that assumes availablity of a tmp dir
01:14:13 * ds wanders off into weird "what if's"
01:14:44 tim: I have nothing against a GstBuffer * "data" property, it just seems weird to me not to provide a gchar * "location" property that's all
01:14:51 tim: anyway, it's late, I should probably go to sleep
01:15:26 ds: sure.  I just felt a few lines in core would make the location property moot