[vlc-devel] [PATCH 1/5] core: move input.c to input_internal.c
thomas at gllm.fr
Wed Jul 11 09:05:47 CEST 2018
I prefer the following renaming
input_thread_t => vlc_input_t
input_manager => vlc_player_t
On question, should internal symbols used across several objects have the vlc_ prefix ?
On Tue, Jul 10, 2018, at 18:53, Denis Charmet wrote:
> On 2018-07-10 18:24, Rémi Denis-Courmont wrote:
> > Le tiistaina 10. heinäkuuta 2018, 16.43.05 EEST Thomas Guillem a écrit
> > :
> >> Leave input.c for the future "input manager", that will be called
> >> vlc_input_t.
> > Jokes aside, I don't think the input thread parent can be described as
> > an
> > input, really. In LibVLC side, the corresponding object type is called
> > media
> > player, not input - and it manages both inputs and outputs.
> > So while I agree that manager is not a very inspired word for a name,
> > I would
> > argue that input is even less inspired. The best I can come up with is
> > vlc_player_t, vlc_media_player_t or vlc_media_handler_t but there are
> > probably
> > better options.
> vlc_playback_manager_t, vlc_playback_controller_t...
> I agree that we have way too many input_foo_t structures and it's very
> difficult to understand what's an input_thread_t, input_item_t without
> even counting the priv versions.
> If the goal of this new module is to add sources, play/control them and
> centralize the events then it's a player in itself. As long as it
> doesn't collide with the libvlc apis.
> TBH, I don't really have strong opinion on names and will agree with
> anything close enough but it would gain me time not to have yet another
> input_whatever to recheck each time which does what. :)
> Denis Charmet - TypX
> Le mauvais esprit est un art de vivre
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel