From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm0-f47.google.com ([74.125.82.47]) by ur; Sun Jul 17 17:42:57 EDT 2016 Received: by mail-wm0-f47.google.com with SMTP id i5so92880180wmg.0 for <9front@9front.org>; Sun, 17 Jul 2016 14:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=dQ3Bi32O0qf2XltFQpqLmjpccGGAfz0qScaTfjn+gfE=; b=W18Sb43iQXced+7n1GffDs2S3BPzSVoyEOSA3JPs9avZqLRDIUy/b9mTKwZObEqWdB P0JoIuVp5Rs/VcmZXedu64yIEaQaZBMcnRR18eSNzREFpYdEZcXhf2DOP3qremjdLkad F+5CYHjm7jy1znUIB85CJRskexadykwtUG9nKA8YvShjx8coP3WjGpUnPin2as5aIMVq 7zCqY7Cs0ZFrFzLlFyAsgIGKWsyRvsB6gF+m9Nh05AisjMW8mIAiPPoq5o1dY1DQrfU2 qmRQbJ3Q/idjQy1KWdPbgoMFiVg+hJrsITwncQvOsIsFaiT4xQf65SlRgqrKzj8EAYAK gO/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=dQ3Bi32O0qf2XltFQpqLmjpccGGAfz0qScaTfjn+gfE=; b=QAoYe976NUOkUq40KuVhv36OZB/h+oycmSDHidppLXhnBH0S2Sl8GfmJbpqJPxdCFI Q0zvIX5Dctt5dzQJxfGLEPIobSTXCh3nzo4BveYd3wSqioQvsHdRVESKCak2bU3o+pY/ UK7aP5xbIM1JmT1j3oGOeY6WGTNJRstL2MKzO3V13h8t2qHDsoUPTjJgVJG3/abg6T+s tGgKj+CrGFMItaZ/evJ8BMayeOYvMCpe/44MzAUuWewFII+/FYhjyjYz0ud/zCMagzpc fsP/Q61IF4aP7RLumbsNwYD06/mvXOefUAhF2KcKMKpmdmVyVXm5PA+w1PTOSNZwXlBL rlqA== X-Gm-Message-State: ALyK8tJRsgOM+JQRXPNQIp8nhe8h5TTe6ZddJ60JkAagikVmuU1+F+qmY7nRVvchLTYg0No1oV+Cq2lRer5yFA== X-Received: by 10.28.152.5 with SMTP id a5mr34485332wme.76.1468791774700; Sun, 17 Jul 2016 14:42:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.185.77 with HTTP; Sun, 17 Jul 2016 14:42:53 -0700 (PDT) In-Reply-To: References: <53e1050bb6a13f58ad4026ea6814b8dd@dl.attlocal.net> <9eacbf8e-72f0-41f7-b7a5-b8c119a1b1b4@email.android.com> <82ce0e72-31d0-4c6e-88f4-8e89590a64ca@email.android.com> From: =?UTF-8?B?QWRhbSBNcsOzd2th?= Date: Sun, 17 Jul 2016 23:42:53 +0200 Message-ID: Subject: Re: [9front] drawterm mouse settings To: 9front@9front.org Content-Type: multipart/alternative; boundary=001a114b298cfaedf60537dbbb0a List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: flexible open STM high-performance ACPI over SOAP information reduce/map control --001a114b298cfaedf60537dbbb0a Content-Type: text/plain; charset=UTF-8 modified drawterm /kern/devmouse.c to allow buttonmap command buttonmap xyz or buttonmap (reset to default) whole file http://okturing.com/src/3732/body patch http://okturing.com/src/3736/body i dont know if apply because of SHIFT key modifier (default) that changes mouse button 3 behavior to act like middle mouse 2 button. anyway anon delivers, still if someone is interested. second test. drawterm respects Windows mouse settings, if button is swapped in OS. 2016-07-13 11:56 GMT+02:00 hiro <23hiro@gmail.com>: > If I understand correctly this is how the mouse works: > > case MotionNotify: > me = (XMotionEvent *)e; > s = me->state; > ms.xy.x = me->x; > ms.xy.y = me->y; > ms.msec = me->time; > break; > > > > On 7/13/16, stanley lieber wrote: > > Dave MacFarlane wrote: > > > >>On Tue, Jul 12, 2016 at 8:22 PM, stanley lieber > >>wrote: > >>> hiro <23hiro@gmail.com> wrote: > >>> > >>>>I was under the impression this is handled by your OS (Xorg for > >>>>example), not inside drawterm. > >>> > >>> So, mousectl is simply not implemented? > >>> > >>> sl > >>> > >> > >>What would it do? Change the settings on the OS of the machine that > >>you're connecting > >>from? > >> > >>- Dave > > > > No, why would anyone expect activity inside the drawterm session to > change > > the behavior of the host OS? > > > > The expected result would be to change the behavior of the mouse inside > the > > drawterm session, just as the mouse(3) bits that are currently > implemented > > facilitate the current behavior of the mouse inside the drawer term > session. > > If I understand correctly, all that is missing here is implementing those > > bits (namely, ctl messages). > > > > Maybe I'm misunderstanding and this is impossible, but if so, how can the > > mouse work at all? Drawterm already intercepts and interprets the mouse, > > right? > > > > sl > > > > > --001a114b298cfaedf60537dbbb0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
modified drawterm /kern/devmouse.c to = allow buttonmap command

buttonmap xyz
or
buttonmap (reset to = default)

whole file h= ttp://okturing.com/src/3732/body
patch http://okturing.com/src/3736/body

i dont know if apply because of SHIFT key modifier (default) that = changes mouse button 3 behavior to act like middle mouse 2 button.
anyway anon delivers, still if someone is interested.

= second test. drawterm respects Windows mouse settings, if button is swapped= in OS.


<= /div>

= 2016-07-13 11:56 GMT+02:00 hiro <23hiro@gmail.com>:
If I understand correctly this is how the mouse wo= rks:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 case MotionNotify:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 me =3D (XMotionEven= t *)e;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 s =3D me->state;=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ms.xy.x =3D me->= x;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ms.xy.y =3D me->= y;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ms.msec =3D me->= time;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;



On 7/13/16, stanley lieber <sl@s= tanleylieber.com> wrote:
> Dave MacFarlane <driusan@gmail= .com> wrote:
>
>>On Tue, Jul 12, 2016 at 8:22 PM, stanley lieber <sl@stanleylieber.com>
>>wrote:
>>> hiro <23hiro@gmail.com<= /a>> wrote:
>>>
>>>>I was under the impression this is handled by your OS (Xorg= for
>>>>example), not inside drawterm.
>>>
>>> So, mousectl is simply not implemented?
>>>
>>> sl
>>>
>>
>>What would it do? Change the settings on the OS of the machine that=
>>you're connecting
>>from?
>>
>>- Dave
>
> No, why would anyone expect activity inside the drawterm session to ch= ange
> the behavior of the host OS?
>
> The expected result would be to change the behavior of the mouse insid= e the
> drawterm session, just as the mouse(3) bits that are currently impleme= nted
> facilitate the current behavior of the mouse inside the drawer term se= ssion.
> If I understand correctly, all that is missing here is implementing th= ose
> bits (namely, ctl messages).
>
> Maybe I'm misunderstanding and this is impossible, but if so, how = can the
> mouse work at all? Drawterm already intercepts and interprets the mous= e,
> right?
>
> sl
>
>

--001a114b298cfaedf60537dbbb0a--