[MPlayer-dev-eng] Re: [PATCH] Cleanup the libvo/input hacks

[Alban Bedel]

On Sat, 29 Oct 2005 22:00:10 +0200
Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:

> Hi,
> On Sat, Oct 29, 2005 at 01:11:57PM +0200, Alban Bedel wrote:
> > On Sat, 29 Oct 2005 00:21:17 +0200
> > Alban Bedel <albeu at free.fr> wrote:
> > > Hi all,
> > > 
> > > Following up the discussion on cvs-log i made the changes. While at it
> > > i did a little more cleanup. So this patch:
> > > 
> > >  * Remove all call to libinput functions from libvo (closing the window in
> > >    win32).
> > >  * Define new keys for vo dfbmga and put some default mappings.
> > >  * Remove the hacks in the x11 input (like mapping O to o, Q to q, etc).
> 
> By making the hack of mapping 'O' and 'Q' that could be used free
> before, too? This seems wrong to me. Why is this needed anyway?

Read more the code more carfully. Currently if you map a command to O
and another to o, and type O you will have different behaviour if the
key enter mplayer via the term or via the movie window :( Their is no
reason for the vo to do such non sense hacks.

> > > A bit of testing would be nice as i can't test the win32 and dfb parts.
> > 
> > It seems it was a bit too late and a few 10L sliped in :) Here come an
> > updated version that also fix a couple other vo.
> 
> IMHO using
> mplayer_put_key(KEY_CLOSE_WIN);
> instead of
> mp_input_queue_cmd(mp_input_parse_cmd("quit"));
> is a giant hack.

Hmm, we probably don't have the same definition ;) imho the various
parts of mplayer should be kept cleanly separated as far as it's possible.
libvo already expect the "core" to provide mplayer_put_key(),
why should it also need the whole libinput stuff ?

> This just is not a key event, it is some completely
> different thing that should make MPlayer quit, and not maybe something
> else the user happened to assign to that key.

That "key" only exist if one input (like a vo) return it. If you really
want to prevent users from remapping that just remove the key name from
the key name list, but i don't really see the point.

> If you really think a input dependency is a problem, we can still introduce
> a mplayer_put_command function.

Why that ? vo should be purely "passive", they have no reason to start
telling the "core" what it should do. They should just pass events down,
then the "core" decide what to do with them.
Sure a better interface than a single int could be used, but currently
it's enouth.

> Also, how sure is it that the KEY_INTERN definition is colission-free?
> Maybe I'm missing something, but currently this has a very bad smell for
> me.

I think it's colission free, but yeah it's a bit messy. Perhaps we should
merge keycodes.h, mouse.h, joystick.h and put some order in these defines.

	Albeu