[MPlayer-dev-eng] [PATCH] propagate mouse movement from vo device

[Nico Sabbi]

Attila Kinali wrote:

>On Fri, 15 Sep 2006 19:19:50 +0200
>Nico Sabbi <nicola_sabbi at fastwebnet.it> wrote:
>
>  
>
>>This patch, written by Jonas Jermann and extended in the rescale() 
>>function by me,
>>is needed to tell mplayer the coordinates of the mouse during movement;
>>it will be used by the dvdnav code to select buttons with the mouse.
>>    
>>
>
>I had a quick look at the code and for me it seems to be
>not so clean. IMHO the rescaling function belongs into
>the vo module. mplayer.c should not know and definitly
>not care about whether the vo module is in full screen
>or not, or whether the coordinates match something.
>IMHO half of rescale_input_coordinates belongs into
>x11_common.c (maybe geometry.c or somewhere more generic
>to be reused in other vo modules too).
>  
>

I disagree: the vo should pass along what the vo (and no other 
component) knows,
nothing else.
The rescaling function depends also  on sh_video, so I  don't see any
reson to make the vo calculate it. Only main() knows all these details,
and moving the function or parts thereof to some other submodule looks 
innatural
to me

>Then, the coordinates should be passed upwards the vf
>chain so that any image size changing vf module can
>translate the coordinate back to what its input format
>was (again, a generic function that can be reused
>would be good).
>  
>

>In the end, mplayer.c should get coordinates that
>do match the original image.
>
>I know, this is a lot more complicated than it is now,
>but if you apply it this way, it will become a total
>mess as soon as someone tries to take -vf crop or expand
>into account.
>  
>

any way to make the filters like scale, crop and expand (or mirror)
adapt the coordinates? they would need to know a lot of details of each
other, making this chain a mess to code for

>IMHO we should really start slowly to seperate the different
>sub modules of mplayer and get rid of all global variables
>so that maintaining and porting becommes simpler. Adding
>new cross-dependencies is IMHO not the right thing to do.
>
>
>				Attila Kinali
>
>  
>

there's no more cross-dependency than there is currently, but
if you advice a simple way to make the patch work I'm all ears