[Spice-devel] [RFC spice-gtk v3 1/1] Gstreamer: Use GstVideoOverlay if possible

Marc-André Lureau marcandre.lureau at gmail.com
Wed May 16 10:19:25 UTC 2018


Hi

On Wed, May 16, 2018 at 12:16 PM, Marc-André Lureau
<marcandre.lureau at gmail.com> wrote:
> Hi
>
> On Wed, May 16, 2018 at 12:09 PM, Christophe Fergeau
> <cfergeau at redhat.com> wrote:
>> On Wed, May 16, 2018 at 10:46:35AM +0200, Christophe Fergeau wrote:
>>> On Wed, May 16, 2018 at 10:43:20AM +0200, Christophe Fergeau wrote:
>>> > On Wed, May 16, 2018 at 10:23:01AM +0300, Snir Sheriber wrote:
>>> > Yes, indeed, this is similar to what you were doing in earlier
>>> > iterations.
>>> >
>>> > > I personally really like the current flow of the request for handle
>>> > > using the signal and getting it as a response, avoiding of setting
>>> > > and getting an handle from different components.
>>> >
>>> > Using signals as some generic way of calling a getter on some unknown
>>> > class is rather unusual, and feels like something you should not really
>>> > be using signals for.
>>>
>>> Just realized, this change is most likely an ABI break:
>>
>> (I promise I'll stop replying to myself :d). Not sure we are supporting
>> inheritance from SpiceDisplayChannel, nor that it makes sense, so maybe
>> not a big problem.
>>
>
> You could in theory, but it's very unlikely someone did.
>
> But I question the "streaming-mode" signal. Who cares about it?
> Shouldn't it be a property instead (with the associated notify::)?
>
> I would remove it unless there is a real use case.

My bad, I understand the reason now, this is actually used as a
callback to get the display window handle.


-- 
Marc-André Lureau


More information about the Spice-devel mailing list