[MPlayer-dev-eng] [PATCH] double click to switch to full screen in GUI

[laurent wozniak]

Diego Biurrun wrote:
> You're making some changes to mouse wheel handling, this could go in a
> separate patch.
>   
Well, this is not possible.
Why is not trivial, and needs some explanation:

Some Background:
The mouse driver treats the mouse wheel as 2 normal buttons.
The only difference is that those 2 buttons (up and down) only send 
mouse press events.
And those buttons can be simulated by real buttons by the mouse itself 
(in some of them, not all),
with a difference that the real buttons also send mouse release events.
So, you cannot split the handling of mouse buttons and mouse wheel, 
since it's the same thing.
Some graphic layers already do this for you, such as direct x, but for 
others, such as x11 or sdl, you have to do it yourself.

Some History:
When I discovered the input layer and video output driver input layer, I 
wanted to see them in action,
before implementing a generic double click solution.
So, I've played with both mplayer and gmplayer and found bugs in the 
existing mouse button handling.
Some mouse button clicks were ignored, some were interpreted twice...

The Problems:
* The gui and the selected vo driver were fighting to handle mouse click 
events.
When in gui mode, the handling was partially done in the vo driver,
but some handling was skipped (because it is known that it will be 
handled by the gui) and some handling was not (see "x11_common.c").
This mix was causing dependency problems, and of course, bugs.
* Each vo driver re-implement the layer to split mouse wheel and mouse 
click when the underlying graphic library was not in charge of doing it.
Duplicated code always leads to bugs.

Solutions:
* I split the mouse click event handling responsibility:
When in gui mode, mouse click events are handled by the gui. Without 
gui, they are handled by the vo driver.
* I've created a new input layer between the mouse click handlers and 
the current input layer.
* I've moved some mouse click handling (especially the mouse wheel) from 
the several previous handlers into the new input layer to factorize code.
* I've added the mouse wheel key, so vo drivers dealing with high level 
events (mouse wheel, double click) pass them through to the new input layer,
which doesn't perform more interpretation (doing so would create bugs).
* Once the mouse click handling was put in a single place and bugs were 
corrected, I could start implementing the mouse double click handling.
* Finally, with your suggestions, I created a workaround for the single 
click not bound logging problem.

As you can read, this patch is more about mouse click handling in 
general, not just mouse double click.
Mouse double click is the visible feature that this patch adds.
But it also correct some bugs (see the list in a previous mail) and 
changes some design.

This is why I cannot slit it. It has to be taken as a whole.

> Why not simply introduce a new command "nop", which we could then bind
> to first button singleclick?  Then no extra logic is needed...
>   
This is what I did: the command "no_command", which does nothing, is 
equivalent to a "nop".
I also though about calling it "nop", but this name has a strong 
assembly meaning...
And as you suggest, it is bound to mouse single click.
The execution of the command itself is short-circuited at command 
parsing time, just before evaluation.
So I hadn't had to write the "nop" command body.

(By the way, key commands could be parsed once and for all at binding 
initialization time instead of being recompiled every time before 
execution.)

The only difference is that the binding is automatic, it does not 
require to be specified in any configuration.
So, a user binding a mouse double click X in its configuration file 
doesn't have to bother about also having to bind the corresponding 
single click to "nop".


Conclusion:
Well, I hope you find the patch is OK.
I remember it just started with a quick and dirty hack in the gui event 
loop...

Cheers,
Laurent