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

[Marc-André Lureau]

On Wed, May 16, 2018 at 3:54 PM, Frediano Ziglio <fziglio 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.
>>
>> Christophe
>>
>
> Then class should be declare final is possible and details removed from
> public interface.
> Looking also at 941f4adf1322a5d2548af676059003df17613b47 seems to confirm
> that this class was never meant to be inherited.

That's a commit from 0.1 era ;)

We may have made some mistakes, but in theory, we bumped
major/minor/etc correctly enough whenever adding/modifying/removing
interface (breaking ABI).

During next break (some day), we may use the opportunity to make make
most channel classes final. This is not a priority though. In the
meantime, we don't need to add class signal handlers, and simply use
the private struct for data.

>
> Frediano
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel



-- 
Marc-André Lureau