Re: [9front] Mouse clipping patch

[hiro <23hiro@gmail.com>]

so hitting delete will always make the user escape if an unbehaving
evil program does the clip?
or is there another standard way for the end-user to escape this?

On 7/13/21, José Miguel Sánchez García <soy.jmi2k@gmail.com> wrote:
> 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?
>>
>