[vlc-devel] [vlc-commits] skins2: ensure playlist gets stopped before terminating vlc.

[Alexandre Janniaux]

Hi,

On Tue, Dec 03, 2019 at 08:59:09PM +0200, Rémi Denis-Courmont wrote:
> Le tiistaina 3. joulukuuta 2019, 20.28.07 EET Alexandre Janniaux a écrit :
> > Hi,
> >
> > On Tue, Dec 03, 2019 at 08:06:49PM +0200, Rémi Denis-Courmont wrote:
> > > Le tiistaina 3. joulukuuta 2019, 15.14.27 EET Alexandre Janniaux a écrit :
> > > > There is no example of how it should be done.
> > >
> > > The problem that Erwan describes, where the same system resources sustain
> > > both the GUI and the video window but it's undefined which gets released
> > > first, is a text book case of reference counting. Surely, you don't need
> > > an example of reference counting. Thus, that problem is entirely within
> > > the plugin that contains the GUI and window provider, and does not
> > > concern the core in any way.
> >
> > I agree that refcounting solve this, as I mentioned it in
> > previous mails, but don't agree that it is the correct
> > solution in a case where the two resources have a
> > hierarchical links and which is solvable without refcount.
> >
> > Refcounting comes with its own flaws and is far harder to
> > implement in the current state for the reasons your mention
> > below.
>
> Sure - it can be argued that there is a hierarchy. In fact, that's how it
> works in LibVLC apps.

Indeed.

>
> But then, that implies that the "main" interface is started before the
> playlist, so that it can register the callback to allocate the video window
> early enough.

Why would the implementation need that ?

> And that means the "main" interface must be started and stopped
> in two phases, one before and one after the playlist is respectively started
> or stopped.

I agree that we cannot do that, been there.

> And it can also be argued that there is no hierarchy. The original window
> embedding system relied on reparenting to move the video into and out of the
> interface when the interface was created and destroyed (though the
> implementation was riddled with races and highly prone to crashes).

I don't see how reparenting widgets at the Qt level change
anything to a hierarchy of lifetime. I don't think it is
a releveant example even if I agree with the hacks being
done with a stable widget to workaround xid changes.

IMHO, that's a different layer which is already in the
interface implementation.


The main point of my refactoring was:

Interfaces wants to create window, but the current way to
create windows is through probing window modules.

Solving this leads to a lot of simplification on how window
lifecycle is handled, much like what we're discussing with
Erwan.


Regards,
--
Alexandre Janniaux
Videolabs