[vlc-devel] RE : [RFC] Key press handling

[Laurent Aimar]

Hi,

On Tue, Aug 11, 2009, Rémi Denis-Courmont wrote:
> Le mardi 11 août 2009 21:33:15 Laurent Aimar, vous avez écrit :
> >  For the same reasons, I would prefer to keep the keys event going through
> > the vout, it would allow some nice features in case we have Picture In
> > Picture or thing like that.
> 
> The reason why this will never work properly were already outlined. Interfaces 
> with window providers, as well as several external applications, need to 
> handle keys themselves.
 For that problem, there is 2 solutions:
 - not grabbing the key at all (--vout-event X I think)
 - grabbing it and then giving the event back by another mean.

> This is not some matter of principle. It's a real 
> problem.
 I like when you use dramatical phrases like that ;)

> If someone ever bother to scope key presses to videos instead of VLC 
> instance, (s)he can always extend your new video/window event callback system. 
> In that regard, it is irrelevant whether the key presses are received from the 
> system by the display or the window. Also, regardless of display vs window, 
> this will break globalhotkeys, RC, and Qt4 at the very least - they all 
> generate key press events /out of the blue/ :(
 It's just that a key event has multiple sources: a window, an interface,
globalhotkeys, etc.
 Obviously, for a given source you have more or less information on which
object it will apply to.
 For example, a key saying "fullscreen" coming from globalhotkeys won't tell
you which video window must go to fullscreen, whereas a key coming from
a window is more obvious.  I don't want to loose that information (we don't
actually use it and that's a problem).
 For that, I don't think it's the window provider job to associate itself to a
vout or to an input. Giving the event to the vout would allow easy association
to the vout and to the input and so up to the ES (I don't say that the vout
should then process the event, it can then be sent somewhere, I don't care).

> Anyway, window provider need to handle key presses in any case, if only 
> because they can have the focus. By moving key press to window, we kill many 
> birds with a single stone: the hotkey thread, duplicate source code, 
> quintiplicated binary code (GLX+XvMC+Xv+X11), non-functional Qt4 shortcuts, 
> broken key press handling when goign to fullscreen mode in a LibVLC app...
 I don't see how that will fix the Qt4 shortcuts problems with non embed
window. For that one, I still think that the window provider should not process
the key event, but just send it to the vout which will then send it to a
centralized place (while tracking it sources).
 I am not sure yet how to interact with the interfaces, but it should not be
difficult.

 Btw, do not forget about how to handle hotkeys that interact with DVD menus
or teletext page selection (this one is less critical).

 Anyway, I am not pushing for a solution, just looking for the right one
without forgetting any problems (I don't know all the issues associated with
the hotkey problem hence my questions and point of views).

-- 
fenrir