[Gstreamer-bugs] [Bug 125739] Changed - GstPropertyProbe interface

[bugzilla-daemon at widget.gnome.org]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=125739

Changed by rbultje at ronald.bitfreak.net.

--- shadow/125739	Wed Oct 29 00:15:32 2003
+++ shadow/125739.tmp.20330	Wed Oct 29 06:29:26 2003
@@ -41,6 +41,55 @@
 
 
 ------- Additional Comments From ds at schleef.org  2003-10-29 00:15 -------
 Created an attachment (id=21028)
 new patch
 
+
+------- Additional Comments From rbultje at ronald.bitfreak.net  2003-10-29 06:29 -------
+Several comments:
+
++  if (!gst_library_load ("gstmixer"))
++    return FALSE;
++
++  if (!gst_library_load ("gstpropertyprobe"))
++    return FALSE;
+
+That will not work. Applications need to link to the API, too (e.g.
+the _get_type () function), so you can't gst_library_load () in the
+application. I'd suggest to revert this. It will only work uninstalled.
+
+gst_ossprobe_probe_property (GstElement *element, const char *property)
+
+How about making that a GParamSpec? In that way, you can do a switch
+(spec->param_id) instead of a series of strcmp()s, just like in
+_set_property() and _get_property(). It looks a bit more
+gobject'ish... You could even consider making the probe_property
+functions that the app calls and the virtual functions not-the-same,
+just like in GObject. this means that you get the param_id and the
+GParamSpec in the plugins, but the app can choose to call a
+string-based or a GParamSpec-based property_probe().
+
+How are get_property_info() and probe_property() different? It seems
+like one probes actively, and the other returns the cached probe
+result. Imo, the app shouldn't care, it's up to the plugin to decide.
+The plugin knows better than the app when to free its cache.
+
++  for (i=0;i<4;i++) {
++    char *devname = g_strdup_printf ("/dev/mixer%d", i);
++    int fd;
++
++    fd = open (devname, O_RDONLY);
++
++    if (fd >= 0) {
++      g_ptr_array_add(ptr_array, devname);
++      close (fd);
++    } else {
++      g_free(devname);
++    }
++  }
+
+Will result in issues. See gstosselement.c on how to open a device
+non-blocking. Imo, we should use gst_osselement_open() instead of
+open() even for probing. I'd personally suggest to create the
+probe-list at _class_init() time, not in the probe function, since the
+element can then be in another state than NULL.