drawterm mouse settings

drawterm mouse settings

[sl]

Is there any way to modify mouse settings (a la mouse(3)) for a
drawterm session?

I've never tried to do this before, but it appears drawterm does
not provide a mousectl file, only a mouse file.

sl

Re: [9front] drawterm mouse settings

[hiro]

I was under the impression this is handled by your OS (Xorg for
example), not inside drawterm.

Re: [9front] drawterm mouse settings

[stanley lieber]

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

Re: [9front] drawterm mouse settings

[Dave MacFarlane]

On Tue, Jul 12, 2016 at 8:22 PM, stanley lieber <sl@stanleylieber.com> 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

Re: [9front] drawterm mouse settings

[stanley lieber]

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> 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

Re: [9front] drawterm mouse settings

[hiro]

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 <sl@stanleylieber.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> 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
>
>

Re: [9front] drawterm mouse settings

[Adam Mrówka]

[-- Attachment #1: Type: text/plain, Size: 2039 bytes --]

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 <sl@stanleylieber.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> 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
> >
> >
>

[-- Attachment #2: Type: text/html, Size: 3240 bytes --]

Re: [9front] drawterm mouse settings

[cinap_lenrek]

looks ok, but there are bugs. the permissions are set wrong in the Dirtab
for the mousectl file, the queue entry is accessed at the wrong place
and the code doesnt match the style.

i'v applied a change based on 9fronts devmouse implementing the other
mousectl's as well and which preserves the coding style.

--
cinap