[vlc-devel] [PATCH 5/5] core: first cleaning of input_thread_t variables/event

Rémi Denis-Courmont remi at remlab.net
Tue Jul 10 18:31:42 CEST 2018

Le tiistaina 10. heinäkuuta 2018, 16.43.09 EEST Thomas Guillem a écrit :
> Currently, the input_thread_t is controllable by either input_Control,
> specific functions, by variables or by the 3 previous solutions. Some
> functionalities are only controllable by variables (chapter for example).
> The goal of this commit is to remove variables usage when it's not
> necessary. This commit doesn't remove variables that should be used to pass
> users settings (cf.  input_ConfigVarInit).
> The "intf-event" callback is replaced by the new callback
> input_thread_events_cb that pass a new event: struct vlc_input_event.

I would go even further and replace it with a structure of callbacks, one per 
event type, if only to maximize type safety.

> There
> can be only one listener: the creator of the input_thread_t. In the future,
> the new vlc input manager will receive these events and forward them to all
> listeners.


> In the meantime, I added input_LegacyVarInit,
> input_LegacyVarStop, and input_LegacyEvents, 3 helpers functions that
> reproduce the legacy variable behavior (transform new vlc_input_event to
> old intf-event events). These 3 functions are meant to be removed for 4.0
> release (when vlc input manager is added).
> For now, the playlist and the media_player still use the legacy variables.
> VLM, modules, and the preparser use the new event handling.
> FIXME: there are some functionalities that are only controlable by
> variables, like chapter selection, I need then to add a public API or a
> public INPUT_CONTROL for thoses.

I think APIs are better than controls, also for the sake of type safety.

The internal input controls from input_control_e are (currently) needed for 
message passing to the input thread. But the external controls from 
input_query_e do not seem to have any real motivation.

More information about the vlc-devel mailing list