[gst-devel] adding a simple scheduler warning

[Andy W. <wi...@po...>]

hi. here is a proposal to make the life of an application developer
easier by providing useful warnings, and possibly preventing spurious
bug reports.

let's examine the 'ghost pad' concept. ghost pads are really just
symbolic links, so to speak, that can give the appearance that a bin has
pads. why would i want to give the appearance that a bin has pads? well,
if i construct some complicated source that i would like to act like an
element. i do this in beatbox with an element that autoplugs from a
disksrc to audio output. the app shouldn't care about the autoplugging
pipeline.

at first, i naively descended the BbxPlugin struct from GstPipeline. I
ghosted the autoplugger output to the BbxPlugin's 'src' pad, and
expected things to work. I even filed a bug report when it didn't work.
I wasn't fully aware that the pipeline would have a different sched from
the plugin, so i needed a decoupled element. I then changed the hierachy
so that BbxPlugin descended from a Bin, and so all will be well after i
fix some bugs.



ok, that's the history. this sort of thing can be prevented if we WARN
if a non-decoupled element has a pad ghosted to a managing bin.

read that last sentence carefully.

that is because if i really wanted the bin to be a managing bin, i.e. a
pipeline or a thread, i would have put a decoupled element there anyway.
if i didn't know what i was doing (as i didn't before and as i don't
expect people to do in the future), this error would help me track down
the problem and fix it.


THE ONLY DRAWBACK that i could potentially see from this would be if you
chose to instead put your decoupled element outside the bin, as in
"queue ! { fakesink }" instead of "! { queue ! fakesink }" that would
raise a warning. but we could refine the check to occur in
gst_pad_connect() instead.


any objections or concerns?

wingo.