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

[Rémi Denis-Courmont]

On Tue, 11 Aug 2009 22:47:48 +0200, Laurent Aimar <fenrir at via.ecp.fr>
wrote:
>> 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)

Well, that works for external apps. But what's the point for Qt4 (and I
guess Skins)? We already have and nned the code for Qt4-to-VLC key
conversion anyway.

>  - grabbing it and then giving the event back by another mean.

In theory, we can do that. However, that does not integrate with UI
frameworks quite right; the LibVLC application/interfaces would have to
re-invent key events handling just for the VLC video widget. Also, I would
rather not leak the VLC key codes through LibVLC, to the external
applications. On top of that, this nullifies all the keys that VLC does not
understand but the interface or external application does understand.

(...)
>  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).

Sure. That's why you added an owner to the video windows. Loosing the
information is an orthogonal issue to me. In other words, we are currently
loosing the information either way, and we could preserve it either way as
well.

>  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).

I fail to see why it would be the job of the video display any better than
that of the video window. The job of the video display is to render
pictures in the most efficient way. The job of the video window is to
interact with the windowing system... precisely where focus and key
handling belongs.

I think we all agree that the *processing* of the event does not belong in
the window. It does not belong in the display either for that matter. In
fact, if we ever want to support rendering to pixmaps, we must get rid of
key press handing in the display (unfortunately, mouse too, so not feasible
just yet).

(...)
>  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).

It won't fix it, but I am not convinced it should fix _that_ problem. If we
really want to have Qt4 shortcuts in the non-embedded case, Qt4 should
perhaps provide a non-embedded window too - well that's partly design a
decision for the Qt4 UI. I am not claiming to solve all the misery in this
world ;)

>  I am not sure yet how to interact with the interfaces, but it should not
> be difficult.

This amounts to re-injecting keys from VLC into UI frameworks. I still
don't see any *advantage*, and I already explained why it would suck
(IMHO).
 
>  Btw, do not forget about how to handle hotkeys that interact with DVD
> menus or teletext page selection (this one is less critical).

That will be a problem when/if key press events get scoped. But as I said,
this will need changes in all key press emitters and handlers, regardless
what emits the events (display, window, interface, whatever). I guess we
would need to pass the key press through the "owner" event callback, and
from there up the chain to the elementary stream... ?

-- 
Rémi Denis-Courmont