Here are the fixed patches: - The libdraw patch wouldn't compile due to a missing declaration. Oops! - Fixed a bug where clicking a window border wouldn't focus it (kvik noticed it right away). - Fixed the rect parsing code in rio. - Changed naming convention to clip/unclip. - Documented my changes in mouse(2) and mouse(3). I've included a patch for qwx's quake2 (https://shithub.us/qwx/qk2/HEAD/info.html) which, while not replacing the old grabbing behavior, makes it impossible for the cursor to escape the window. It relies on the forced unclip (no unclipmouse to be seen in the code), so it also serves as a demonstration of that feature. Finally, I've also included a simple rc script to clip the mouse. I've used it to test all the interactions of this new clip feature with rio, as it's easy to invoke, easy to kill with Del, and you have access to rio menus (so you can "exit the clip" by creating a new window which unfocuses the current one). On Tue, Jul 13, 2021 at 5:14 AM José Miguel Sánchez García 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 wrote: > > > > Quoth José Miguel Sánchez García : > > > 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? > >