[vlc-devel] [PATCH] - Proposal for a new hotkeys design

[Laurent Aimar]

On Mon, Oct 27, 2008, brezhoneg1 wrote:
> Hello,
> 
>    This patch is aimed at making hotkeys work with multiple inputs /
> multiple windows.
> 
>    Up to now, a single hotkeys interface and two variables
> "key-pressed/key-action" at the libvlc level are responsible for
> collecting all key-pressed within an instance wherever they come from
> (either vout windows or GUI interface). The hotkeys module then selects
> the input from the playlist if available and a vout at random to display
> OSD messages.
> 
>   This way of working prevents libvlc api and vlm from benefiting from
> some hotkeys (their inputs are not attached to the playlist) and
> potentially mixes up things for other hotkeys (e.g a vout is chosen at
> random for snapshot Shift-S)
> 
>   This patch tries to solve the problem by replicating the three
> elements (two variables "key-pressed"/"key-action" and the hotkeys
> plugin) at the vout (video output)level.
> - What existed at the libvlc level still exists to keep on servicing
> key-pressed from the QT4 GUI
> - Each vout (video output) entity has got its own
> "key-pressed/key-action" and hotkeys plugin attached to it to service
> key-pressed from the window it is in charge of.
> In other words, this patch allows each window to have its own dedicated
> hotkeys thread.

 There is a few problems in its current form but should be easy to fix.

 There is code that does add callback on p_libvlc key-pressed and key-action
and depends on them correctly be called.
 So I would propose to:
 - forward key-pressed and key-action (not sure if both should be forwarded,
 maybe only key-pressed no ?) to p_libvlc when you are a hotkey module attached
 to a vout.
 - to process vout dependant actions when and only when attached to a vout .
 - to process *non* vout dependant actions when and only when *not attached to
 a vout.

Do you see any problem with such modifications ?

-- 
fenrir