Re: mousebound left release script fires on press, not waiting for release (v 101 i 2)
Dana Jansens <[email protected]> Thu, 12 Oct 2017 15:25:11 -0400
| Newsgroups | gmane.comp.window-managers.openbox |
|---|---|
| Message-ID | <CAP1a_aezMAwUD9H99hE3bECKCbpPkUk=72j2zXpXwnpPRmwRow@mail.gmail.com> |
--===============2131783331272101125== Content-Type: multipart/alternative; boundary="001a11372b44347e71055b5e8126" --001a11372b44347e71055b5e8126 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 12, 2017 at 3:22 PM, Plmalternate Plmalternate < [email protected]> wrote: > Thank you, both. > > > From: Paul <[email protected]> > > Do the mouse press and release events register appropriately, according > to > > xev? > Looks ok to me, but I'm not an xev expert. With xev in lxterminal: > On press: > > ButtonPress event, serial 25, synthetic NO, window 0x2a00001, > root 0x497, subw 0x2a00002, time 129612230, (28,20), root:(32,64), > state 0x10, button 1, same_screen YES > > EnterNotify event, serial 25, synthetic NO, window 0x2a00001, > root 0x497, subw 0x0, time 129612231, (28,20), root:(32,64), > mode NotifyGrab, detail NotifyInferior, same_screen YES, > focus YES, state 272 > > On release: > > ButtonRelease event, serial 25, synthetic NO, window 0x2a00001, > root 0x497, subw 0x2a00002, time 129616400, (28,20), root:(32,64), > state 0x110, button 1, same_screen YES > > > > From: Dana Jansens <[email protected]> > > I believe the "client" area behaves differently than other targets > because > > it needs to pass the mouse click thru to the application. So it ends up > > being immediately released from the WM point of view. > I don't follow you. "Needs to pass" or simply "does pass"? Why a need > to pass a click instead of a press? The program running the content of > the underlying window can respond to a press differently from a click. > I just tested that to be sure & in Pale Moon, on items in 2 different > kinds of context menu (highlighted text & tab) I tried pressing, > waiting, releasing; pressing, moving the pointer, releasing; & plain > clicking. The response suggests Pale Moon at least doesn't treat a > press the same as a click, which, to me, suggests OB is passing them > differently. Those context menu items don't execute until a release > with the pointer still over them. For example, I can press "close tabs > to the right" but it doesn't happen until I release. And it doesn't > happen at all if I move the pointer off the menu before releasing > button 1. > > Even if this is a bug, or semi-bug/missing_feature, & not just me > being dumb, don't break your neck on this, galuys. For my immediate > purpose, I've worked around this. But I would like to understand it. > Sorry, let me try again. When Openbox gets the press event in the "client" target area, it immediately hands control of the pointer to the application, so that the application can get the press (and release) events. That means Openbox will not get a release event ever, so it just considers it a click+release immediately. Does that make more sense? > _______________________________________________ > openbox mailing list > [email protected] > http://icculus.org/mailman/listinfo/openbox --001a11372b44347e71055b5e8126 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T= hu, Oct 12, 2017 at 3:22 PM, Plmalternate Plmalternate <span dir=3D"ltr">&l= t;<a href=3D"mailto:[email protected]" target=3D"_blank">plmalternate@= gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thank yo= u, both.<br> <br> > From: Paul <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a><wbr>><br> > Do the mouse press and release events register appropriately, accordin= g to<br> > xev?<br> Looks ok to me, but I'm not an xev expert. With xev in lxterminal:<br> On press:<br> <br> ButtonPress event, serial 25, synthetic NO, window 0x2a00001,<br> =C2=A0 =C2=A0 root 0x497, subw 0x2a00002, time 129612230, (28,20), root:(32= ,64),<br> =C2=A0 =C2=A0 state 0x10, button 1, same_screen YES<br> <br> EnterNotify event, serial 25, synthetic NO, window 0x2a00001,<br> =C2=A0 =C2=A0 root 0x497, subw 0x0, time 129612231, (28,20), root:(32,64),<= br> =C2=A0 =C2=A0 mode NotifyGrab, detail NotifyInferior, same_screen YES,<br> =C2=A0 =C2=A0 focus YES, state 272<br> <br> On release:<br> <br> ButtonRelease event, serial 25, synthetic NO, window 0x2a00001,<br> =C2=A0 =C2=A0 root 0x497, subw 0x2a00002, time 129616400, (28,20), root:(32= ,64),<br> =C2=A0 =C2=A0 state 0x110, button 1, same_screen YES<br> <br> <br> > From: Dana Jansens <<a href=3D"mailto:[email protected]" target=3D"_= blank">[email protected]</a>><br> > I believe the "client" area behaves differently than other t= argets because<br> > it needs to pass the mouse click thru to the application. So it ends u= p<br> > being immediately released from the WM point of view.<br> I don't follow you. "Needs to pass" or simply "does pass= "? Why a need<br> to pass a click instead of a press? The program running the content of<br> the underlying window can respond to a press differently from a click.<br> I=C2=A0 just tested that to be sure & in Pale Moon, on items in 2 diffe= rent<br> kinds of context menu (highlighted text & tab) I tried pressing,<br> waiting, releasing; pressing, moving the pointer, releasing; & plain<br= > clicking. The response suggests Pale Moon at least doesn't treat a<br> press the same as a click, which, to me, suggests OB is passing them<br> differently. Those context menu items don't execute until a release<br> with the pointer still over them. For example, I can press "close tabs= <br> to the right" but it doesn't happen until I release. And it doesn&= #39;t<br> happen at all if I move the pointer off the menu before releasing<br> button 1.<br> <br> Even if this is a bug, or semi-bug/missing_feature, & not just me<br> being dumb, don't break your neck on this, galuys.=C2=A0 For my immedia= te<br> purpose, I've worked around this. But I would like to understand it.<br= ></blockquote><div><br></div><div>Sorry, let me try again. When Openbox get= s the press event in the "client" target area, it immediately han= ds control of the pointer to the application, so that the application can g= et the press (and release) events. That means Openbox will not get a releas= e event ever, so it just considers it a click+release immediately. Does tha= t make more sense?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> ______________________________<wbr>_________________<br> openbox mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= g</a><br> <a href=3D"http://icculus.org/mailman/listinfo/openbox" rel=3D"noreferrer" = target=3D"_blank">http://icculus.org/mailman/lis<wbr>tinfo/openbox</a></blo= ckquote></div><br></div></div> --001a11372b44347e71055b5e8126-- --===============2131783331272101125== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kb3BlbmJveCBt YWlsaW5nIGxpc3QKb3BlbmJveEBpY2N1bHVzLm9yZwpodHRwOi8vaWNjdWx1cy5vcmcvbWFpbG1h bi9saXN0aW5mby9vcGVuYm94 --===============2131783331272101125==--