From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 9543 invoked from network); 13 Jul 2021 10:13:25 -0000
Received: from 1ess.inri.net (216.126.196.35)
  by inbox.vuxu.org with ESMTPUTF8; 13 Jul 2021 10:13:25 -0000
Received: from mimir.eigenstate.org ([206.124.132.107]) by 1ess; Mon Jul 12 22:36:50 -0400 2021
Received: from abbatoir.myfiosgateway.com (pool-74-108-56-225.nycmny.fios.verizon.net [74.108.56.225])
	by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 188ce8dd (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO)
	for <9front@9front.org>;
	Mon, 12 Jul 2021 19:36:28 -0700 (PDT)
Message-ID: <8CE29EA89CBA8F74C1D4D8EEF2528473@eigenstate.org>
To: 9front@9front.org
Date: Mon, 12 Jul 2021 22:36:27 -0400
From: ori@eigenstate.org
In-Reply-To: <CAA85C879ggSM=fPu+CcgToakbhMh2Rk=A5gn3AWsPUqUYGFckQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: configuration strategy-scale software manager 
Subject: Re: [9front] Mouse clipping patch
Reply-To: 9front@9front.org
Precedence: bulk

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?