Re: [9front] Mouse clipping patch

["José Miguel Sánchez García" <soy.jmi2k@gmail.com>]

Let's see if I can do this quote thing correctly:

First of all: I'm aware of some bugs (and you pointed out others)!
I'll send the corrected patchset tomorrow.
The naming scheme is a bit messy as a result of a dropped feature.
I'll improve it too.

> Don't do this to vncv! Not grabbing the mouse makes it
> much more usable.

I'm aware of someone who will respectfully disagree :-)

> For the other programs that can use it, I assume the
> patches will follow up once we're happy with this patch
> set?

Sure, they'll come later. I wanted to keep them separated from these.

> Not sure that this is necessary. Your mouse being
> constrained to the window is probably enough hint.

Keep in mind that the border changes not only for the window currently
grabbing the window, but for any non-current window "grabbing" it too
(even if it doesn't apply because it's not focused). The different
border color serves as an indicator that, when you focus it, it will
grab your mouse. It might avoid an unpleasant surprise. However, if
you feel like it's redundant, it can be easily removed.

> But also, do we need to do it? Is there any case
> where we want to constrain the grab to anything
> other than the whole window? What if the ctl
> messages were just
>
>         trap
>         release
>
> with no further parameters?

The point of allowing arbitrary clip rects is to make the grabbing
program unaware of the existence of a window manager. Rio itself would
be an example of a program which doesn't grab the whole "window" (the
whole screen), but only subrects of it. In order to maintain an
uniform interface which works regardless of the presence of rio or
not, I've decided to go down the simplest route and just allow any
subrect of the whole screen to be clipped. It didn't require more code
or more complex handling, and it even allows future programs to take
advantage of this feature.

Hope it makes sense!

On Tue, Jul 13, 2021 at 4:53 AM <ori@eigenstate.org> wrote:
>
> Quoth José Miguel Sánchez García <soy.jmi2k@gmail.com>:
> > think about vncv, qwx's quake ports, screenlock
>
> Don't do this to vncv! Not grabbing the mouse makes it
> much more usable.
>
> For the other programs that can use it, I assume the
> patches will follow up once we're happy with this patch
> set?
>
> > - Windows holding the mouse have a different border color,
> > so they can be clearly identified.
>
> Not sure that this is necessary. Your mouse being
> constrained to the window is probably enough hint.
>
> > +                     write(mousectl->mctlfd, x->data, cnt);
>
> This will hide all errors from the write, so
> a malformed mousectl message will get silently
> dropped.
>
> > +extern int           clipmouse(Mousectl*, Rectangle);
> > +extern void          releasemouse(Mousectl*);
>
> This naming lacks symmetry.
>
> How about constrainmouse()/releasemouse()?
> Or if you feel cute: mousetrap()/mouserelease()?
>
> Same with the ctl messages: trap/release, or clip/unclip?
>
> > +                     grabr.min.x = strtol(x->data+4, &p, 0);
> > +                     if(p == nil){
>
> This isn't how strtol behaves -- if it can't convert
> the number, it leaves p untouched. you need to do:
>
>         grabr.min.x = strtol(p, &e, 0);
>         if(p == e || *e != ' ')
>                 // error
>         p = e;
>
> You can probably clean it up a bit with tokenize(),
> and then ensure that *e == '\0':
>
>         if(tokenize(x->data+4, coords, 4) != 4)
>                 error()
>         n = strtol(coords[0], &e, 0);
>         if(*e != 0)
>                 error()
>
> But also, do we need to do it? Is there any case
> where we want to constrain the grab to anything
> other than the whole window? What if the ctl
> messages were just
>
>         trap
>         release
>
> with no further parameters?
>