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

[Remi Denis-Courmont]

Le 2019-12-09 20:30, Alexandre Janniaux a écrit :
> 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,

Most likely a waste of time.

> but it is quite the same, isn't it?

The whole point is: no. The video was started before, and destroyed 
after, the GUI. It worked because the video was re-parented into and out 
of the GUI.

That wouldn't have been possible with QtWidget's.

-- 
Rémi Denis-Courmont