[vlc-devel] [vlc-commits] skins2: ensure playlist gets stopped before terminating vlc.
remi at remlab.net
Mon Dec 9 20:48:21 CET 2019
Le 2019-12-09 20:30, Alexandre Janniaux a écrit :
> 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
>> to separate the with and without playlist phases of initialization. In
>> 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
>> starts. The main interface can only register its video window provider
>> if it
>> has started.
>> 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.
More information about the vlc-devel