[vlc-devel] LIBVLC API : feedbacks
rem at videolan.org
Mon Nov 3 19:05:44 CET 2008
Le lundi 3 novembre 2008 18:57:08 brezhoneg1, vous avez écrit :
> Q3: vlc has got two entities: keys and actions. Yet, actions are always
> used together with keys.
> Why not differentiate them further? Actions implementation could be
> moved into the already existing src/misc/action.c. Actions could be made
> available throughout the vlc architecture (not just associated with
> keys). Why not even create a libvlc_trigger_action(media_player,
> actionid) as part of the libvlc api ?
Actions were created as a simple solution to avoid replicating the lookup code
in each and every hotkey handler. This is mere legacy. For any purpose, it is
better to use the proper API directly rather than actions.
> Q4: multiple keys for one action.
> As of today, add_key() function is based on an integer and yet, it is
> stored in config file or read from the command line as a string
> (StringToKey and KeyToString functions used internally).
> Why not change add_key() to become string-based ? Why not then accept
> multiples strings like "key-record=Shift-R:Alt-R:r" (this would be
> consistent with how sub-filters and others are already managed) ?
This brings a lot of complexity. And the benefits aren't obvious to me.
> Q5: libvlc API allows for multiple media_players playing multiple
> videos. Yet, one single hotkeys thread is responsible for monitoring key
> pressed for all windows, leading to a real mess.
> Why not create one hotkeys thread per window to ensure that keys are
> managed independently (see
The hotkey interface was not thought to be used with VLM when it was written.
In fact, VLM did not even exist yet, and a fortiori neither did the LibVLC
> Q6: inputs threads created by media_players (libvlc api) are attached to
> the libvlc object. This prevents them from benefiting from a whole range
> of features where inputs are supposed to be attached to a playlist.
> (str_format_meta function, hotkeys module, ...). Any plans to treat
> these libvlc api inputs on a par with the playlist-attached inputs?
No. The playlist is a playlist. It plays (no more than) one item at a time.
Perhaps some features need to be made independent of the playlist, but this is
a different matter.
More information about the vlc-devel