This event was not used. The aout is unique and created by the playlist (and by
vlc_player in the future), we don't need to send any events for its
creation/deletion.
inputChangedHandler only reads from the current MIM input, which isn't
set until the next playlist callback is received.
This actively probes the current input, sets it, and inform potential
listeners
refs #14162
The input thread sends events. There is no point in checking manually
since the input thread functions aresafe to "use" so long as the caller
has a reference to the input thread (regardless of the input thread
being dead or at EOF). Also the value of those flags can change
asynchronously (outside the input thread) so the checks were racy.
If the input dies, the state changes and the Qt input manager will
delete the input anyway.
Note that checking b_eof and b_dead here is also wrong (no memory
synchronization), but that is left for later.
No way to reproduce bug case.
Fixing by removing all the code.
This reverts commit ddf9e6da14.
This reverts commit c7ab9f113d.
This reverts commit 541c1d97c0.
Some events are fired on each meta type detection, while we just handle
those events on a global change basis.
Qt has some similar deduplication for repaint() or touch events, but
does not provide it to user.
This fixes a race between requesting mute and the aout actually muting.
There are still at least two known bugs with the mute widget:
- Qt tries to sets the LibVLC status when LibVLC status changes
(there is a hack around this for volume but not for mute).
- Qt tracks the playlist "mute" variable instead of the aout one.
Fix issue #4899
The problem was that the playing/paused state was being misreported
to the luahttp interface, turns out this was due to the way the playing
state was being updated in the Qt and hotkey logic.
The p_input state was being updated, but the playlist wasn't being
informed, this patch switches out the p_state calls to use the
equivalent playlist aware functions.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>