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

[Benjamin Otte]

On Wed, 19 Nov 2003, Thomas Vander Stichele wrote:

> 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.
>
I think the xid is just the wrong property to save. You want to use
a property that stays the same between multiple usages of the pipeline.
Íd imagine window names or other hints inside the X server for this.
That way it would work between sessions.

> 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 ?
>
The display should definitely be a property of the X sinks.

> 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 ?
>
We have started to be very careful about what we expose where. There are
multiple ways to manipulate element behaviour and we needed to come up
with clear definitions about where we want to manipulate what.

And we came up with multiple ways:
- Caps are used to define the data that is passed between elements.
Elements should always be free to select any data format they desire (so
no properties here). If you want to manipulate this, use filtered caps.
- Properties are used to define the way an element works. Properties
must work between sessions and on multiple machines as they are used for
serialization. Element behaviour should be described completely with
properties and the caps they are connected to.
- Interfaces are a way to change element behaviour during a session. Its
main use is to abstract the exact element away from the application as
multiple elements can implement the same interface and this gives you the
freedom to manipulate all of them the same way.

There is some overlap obviously as the jobs these different methods
fulfill are not completely distinct.


Anyway, if you want to have a proper (and hard and powerful) way for
client/server interaction, you would want to transmit the interface's
function calls somehow. Setting properties will not be enough to achieve
this. Especially in the future, when interfaces will be more common.

I would say the right way to abstract pipelines and their manipulation
into a client/server model is a problem that is not yet solved :/

Benjamin