[vlc-devel] [PATCH] - Proposal for a new hotkeys design
fenrir at via.ecp.fr
Wed Nov 5 00:18:40 CET 2008
On Mon, Oct 27, 2008, brezhoneg1 wrote:
> 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
Do you see any problem with such modifications ?
More information about the vlc-devel