Re: [9front] Mouse clipping patch

[ori@eigenstate.org]

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?