[gst-devel] Patch: add xid property to xvideosink

[Thomas Vander Stichele]

On Tue, 2003-11-18 at 23:31, Ronald Bultje wrote:
> On Tue, 2003-11-18 at 22:42, Anthony Green wrote:
> > I'm using the XML representation as an interprocess protocol, not for
> > persistance, so it's perfectly valid concept.  The XID of the target
> > window is naturally a component of the redering pipeline, so being able
> > to (optionally) describe it in XML form along with the other element
> > properties makes perfect sense.
> 
> Hm, in that case, you know that you can add extra data to elements' XML?
> Gst-editor does this, for example, to describe the position and size of
> the visual representation of the element in the editor's window. you
> could use this for the same purpose.

I think I understand both sides of the argument.  From our side, I'm
wondering why we want to make it harder to do something that kind of
came naturally and easily with the object model we use.  Sure it's
possible to add code to handle special-case xml stuff.

But the object arguments are natural ways of doing this.  As someone who
added code to save positions in the editor, I'm saying there's a clear
difference between the two use cases.  The editor saves position data on
the canvas as extra xml on the pipelines; the goal here is that the
pipeline itself will still work as a gst pipeline, and the editor can
save properties (position) that are properties of it's own
representation of the pipeline/elements.

In the xid case, the xid is a property of the element itself, that it
needs to function, and in no way is directly relevant to the other
apps.  In effect, the pipeline saved in xml will not run properly
because xid handling works differently depending on the code you write
to support the additional xml properties.

So, while I know that it is possible to write extra code to handle xml,
while knowing that we are writing extra interface code just to handle
the xid, and so on, I still have to ask: what is wrong with having it as
a property ? I have, by the way, the same question for the display
property; right now ximagesink will only look at the DISPLAY env var. 
Why is it bad to add a display property so you can have two ximagesink's
at the same time to different DISPLAY's ?

In short, if developers have a valid need for this possibility, as they
have explained, why are we trying to steer them away from that ? In the
past, we were writing plugins as specialized and specific as possible,
relying on the library and additional elements to present an abstract
similar concept of them.

All of a sudden, we have interfaces, and now we are "dumbing down"
elements to the least common denominator of functionality, then adding
back specialized code to get or set stuff specific to the underlying
library.  Aren't we needlessly complicating stuff there, or do I have
something backwards ?

Thomas



Dave/Dina : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
My shite shits on your shite
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/