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

[Alexandre Janniaux]

Hi,

On Tue, Dec 03, 2019 at 10:27:33PM +0200, Rémi Denis-Courmont wrote:
> Le tiistaina 3. joulukuuta 2019, 21.25.31 EET Alexandre Janniaux a écrit :
> > > 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.
>
> I don't think it's infeasible. It needs core and main interface plugin changes
> to separate the with and without playlist phases of initialization. In any
> case, if it were not feasible, then the hierarchical model is not feasible so
> it sounds like you are contradicting your own self here.

You're right, and actually that's not even what I tried,
which was starting the playlist in two phases instead.
I actually like it the way you present it.

>
> The video window is needed when the playlist starts. No matter how you put it,
> that means the video window provider must be registered before the playlist
> starts. The main interface can only register its video window provider if it
> has started.

Right.

>
> Treating the main interface the same way as the secondary control interface is
> all a big lie anyway as the MacOS interface hijacks the main thread - which is
> essentially only possible for one interface out of all of them.
>

I agree.

> > > 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.
>
> It was of course reparenting the underlying window, not the Qt widget. The Qt
> interface did not even exist at that time. C.f. the old code.

I'll check, but it is quite the same, isn't it?

Regards,
--
Alexandre Janniaux
Videolabs