[MPlayer-cygwin] Mouse buttons fail.

[Lostgallifreyan]

Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
(11/05/2015 20:54)

>On Mon, May 11, 2015 at 08:01:09PM +0100, Lostgallifreyan wrote:
>> On MOUSE_BTN2, the only one that even appears to formally exist, Strange Things happen.
>> I can do MOUSE_BTN2 pause, and that works as it should, but MOUSE_BTN2_DBL fails! I get a no-binding error for MOUSE_BTN2!
>
>It doesn't fail (at least it shouldn't and does not on Linux).
>But the way it works you will always get a MOUSE_BTN2 event before a
>MOUSE_BTN2_DBL one.

Yes, similar in WIndows with either button, and the API has several curious workrounds. In my own coding I learned to handle all the mouse up and down messages directly, and chain the evnts handling myself to get reliable operation without conflict with the native behaviour. (Was an absolute requirement to code a right double-click with the API anyway). This is the trouble, if we can't avoid that native behaviour, we're screwed. :)

>I do admit this limits the usefulness as binding both MOUSE_BTN2 and
>MOUSE_BTN2_DBL will not usually make sense, but there are kind of
>reasonably good reasons for that behaviour.
>The missing bind is not an error however.
>

Wouldn't MOUSE_BTNn-MOUSE_BTNn_DBL be intended to bypass the single click so we can get the double as we want it? Regardless of which button 'n' is, we might want different behaviours, we just need to make sure the one for single is hamless when we go for the double. (In my own coding, I set a timing delay for single sometimes, so if double is complete first, single never gets a shot. It's practical enough, but I rarely used it beyond testing that it worked in Win32 API. Certainly can't do that here, not got that much control).

>> The ONLY mouse buttons that do ANYTHING, are signle right clicks, and (only in full screen) single left clicks). This is woeful, it's apparently better to pretent I have no mouse at all and be done with it!!
>
>The left click thing is a Windows-specific hack necessary to keep
>some strange old features (dragging the Window even by clicking inside
>it).
>You need to press CTRL if you want the left-mouse-clicks to get through
>in Windowed mode.

Nice. At least there is a way. Not tried it as I write this, but it's better than nothing. Usually, a click in a window just sets focus. Dragging isn;t an issue until the drag itself is detected by mouse motion. I had encounters with WIndow focus habits in a GUI for my synthesier when it was still just an editor. Nasty to solve, I admit, but it can be done systematically without restricting user operations with clicks and Alt-tabbing and such. In the case of dragging a window by grabbing its content, that's risky, I think most Windows users would be very happy to lose that and have to grab a title bar instead, just to have their more useful mouse clicks back! :)

>However it looks like there are a few issues related to mouse handling.
>For example "-doubleclick-time 0" seems actually unsupported for even
>-vo directx. In fact, it seems to only work in OS/2...
>

A compelling obervation, in my view enough to base an assertion that rebuilding all the mouse handlign code from scratch may be in order, once there's some consensus on what behaviour people want. The Win32 API is more liberating than it looks, but I have no idea if any of this conflicts with Linux and BSD and all. It might, for all I know.. Small afterthought: double-click timing may often be handled by a specific mouse driver, and may not be under more general OS control, so maybe nothing gets passed to Mplayer to use.


_______________________________________________
>MPlayer-cygwin mailing list
>MPlayer-cygwin at mplayerhq.hu
>https://lists.mplayerhq.hu/mailman/listinfo/mplayer-cygwin