Re: Mouse buttons fail.

Reimar D=F6ffinger <[email protected]> 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_D=
BL 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 ope=
ration without conflict with the native behaviour. (Was an absolute require=
ment 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 s=
o we can get the double as we want it? Regardless of which button 'n' is, w=
e might want different behaviours, we just need to make sure the one for si=
ngle is hamless when we go for the double. (In my own coding, I set a timin=
g 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 tha=
t it worked in Win32 API. Certainly can't do that here, not got that much c=
ontrol).

>> The ONLY mouse buttons that do ANYTHING, are signle right clicks, and (o=
nly in full screen) single left clicks). This is woeful, it's apparently be=
tter 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 bette=
r 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 encount=
ers with WIndow focus habits in a GUI for my synthesier when it was still j=
ust an editor. Nasty to solve, I admit, but it can be done systematically w=
ithout 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 thi=
nk most Windows users would be very happy to lose that and have to grab a t=
itle 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 rebuil=
ding 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 libera=
ting 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-clic=
k timing may often be handled by a specific mouse driver, and may not be un=
der more general OS control, so maybe nothing gets passed to Mplayer to use.


_______________________________________________
>MPlayer-cygwin mailing list
>[email protected]
>https://lists.mplayerhq.hu/mailman/listinfo/mplayer-cygwin