[vlc-devel] Re: configurable hotkeys
Sigmund Augdal
sigmunau at stud.ntnu.no
Wed May 28 12:06:38 CEST 2003
I get the feeling that we are mixing two discussions here. I´ll silently
ignore all discussion about gui frameworks and try to clarify my thoughts on
the hotkey handling.
1: hotkeys could be reported by anyone, and hotkeys could be handled by
anyone. In my current implementation both the hotkeys interface and the intf
part of the dvdplay module read and handle the key events. Both interfaces
and vouts are allowed to report and/or handle key events as they please. As
an example the vout should handle the fullscreen hotkey itself, so that the
right vout turns fullscreen in case of several vouts, and the don´t report
the event. Interfaces could also check what the current hotkey for "quit" is
and set it as an accelerator for the quit menu item (at least with the
wxwindows api this will be much easier that to trap all keypresses and
report them).
2. My current implementation uses a separate interface module to handle
generic key events (as opposed to dvd navigation events). I realize that
this is suboptimal and that this belong in the core. I also realize that the
playlist thread seems like a suitable place. Both because it is idle most of
the time, and because it has access to both the input and the playlist,
which is what most of the actions is about. But, the hotkeys interface
messes with both vout and aout (fullscreen, volume up/down), and this makes
me uncomfortable with putting it in the playlist thread. I see two solutions
to this. Either keep it as a interface module that is allways inserted or
make a generic event queue in the vlc core. The first alternative has the
benefit that it doesn´t break anything, and it is quite easy to implement,
while the other alternative is the "clean" solution.
I hope this makes my thoughts so far clear to people. I don´t have time to
finnish this work up in the near future if people want me to make this a
part of the core, but I could make my code available to others to finnish.
Sigmund
On Wed, May 28, 2003 at 11:09:32AM +0200, Boris Dorès wrote:
> On Wed, May 28, 2003 at 12:32:45AM (GMT+0200), Gildas Bazin wrote:
> > BTW, vouts needs to deal with very low level window events (look at the
> > directx or x11/xvideo plugins). There is no way on earth you'll have access
> > to these events with a high level cross-platform GUI framework
>
> That's a shame for the framework ;-)
>
> > so you can
> > forget about your idea to manage events in the interface plugin that's
> > providing the window.
> >
> > However having platform specific hooks in the interface plugins to be able
> > to pass native window handles to the vout and then let the vout handle the
> > events should be manageable.
>
> Maybe I misunderstood your point, but I can't see why, if there is a
> way for the vout to handle these events, the interface couldn't.
>
> Unless that means that there is no way at all to handle these key
> events for a framework generated window (I don't really know high level
> frameworks so I cannot be positive about one way or the other), which
> would mean no hotkeys in those windows: rather not providing vout
> windows with such messy frameworks...
>
> --
> babal
> --
> This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
> To unsubscribe, please read http://developers.videolan.org/lists.html
> If you are in trouble, please contact <postmaster at videolan.org>
--
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>
More information about the vlc-devel
mailing list