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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16418 invoked from network); 13 Jul 2021 16:11:32 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 13 Jul 2021 16:11:32 -0000 Received: from mail-pg1-f178.google.com ([209.85.215.178]) by 1ess; Tue Jul 13 06:27:35 -0400 2021 Received: by mail-pg1-f178.google.com with SMTP id 62so21238130pgf.1 for <9front@9front.org>; Tue, 13 Jul 2021 03:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=OH1XUqCCFQBQerjk3VNOoxP75rRL8LrR97PYOVoufVQ=; b=HfhWk3fpOUfjRWF2a3bgQ9SN6QF0BLcg4Jqa0ptXdG1IgIOdcrGszOEi63Dd1Ak2AM HdzrlpWBMz37CmNsesBOj0Fsi8cuqNNAYzIu7AvWVnZTGGYgcBHgLD5d6XMX5ZFswC2m NUIYdbDmx4E7pXcdolo7C1IsKdcYEpzXCN4d0LOj7FkcFJYAEds3TfzCB8miLskJr0re fOCJpss0kdUZwoq1ipx1jOPQNB2YR5Ghh1LBvVZdS3tZnC+CBWRt2ZvI9TL+JhNWuh4D l3dYKYcZUmtX7xE2fMbXxSPKjOOevSTtbEOrxubAE7QVzzp3OO4YH+YLoHVRy0lr6CI5 cRDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=OH1XUqCCFQBQerjk3VNOoxP75rRL8LrR97PYOVoufVQ=; b=YbGNV+WbBah6D0RzX/Heb1nJIh67UscDTYZoPvIpg7Ns01rQ8vdXmOJ9SrNVMA7YZt wt35XunfFMmOJq01VWS70wu5AkH7OQkgWAjnSVaF+Qg90SI5Wf+XEY9OTKKgp0DYtZU3 H6Hcxm8ilzE4D24kBMCWEziUfFQKA4e3UVKWxd6tYx08v7U3P9HTRsXLp540lH7EynPD eB3LqaCgSX/IFOA90zEwSi7UIpAKmEH6mOEwBCdE8nmBoY6jm9s5iKixLgvfN4sVZiAQ b8DcxpYH71X1tTku/GBLi2ryaLBL++FWHs4i3Y7/Ao64I+ty+pArelD8mFqc+QSXVy9k mwZQ== X-Gm-Message-State: AOAM530T1ta3rxp5z4h4GUGhlFfmAQ9RYY1prHCszgMpSpm5mgVgwRfk yYeH995yxoj4l825li8fDNnkhz7PARMWPyeugmIENq6r X-Google-Smtp-Source: ABdhPJxbZ4cCNPTXGiZveVCsMEuiTc4OIZ5S2oXOGbCYnQYD1i4QevmY/FTshk8B1ivpPshrg81KBUapL2Y40+gAtjA= X-Received: by 2002:aa7:943b:0:b029:321:809a:f0b with SMTP id y27-20020aa7943b0000b0290321809a0f0bmr4007167pfo.32.1626172048494; Tue, 13 Jul 2021 03:27:28 -0700 (PDT) MIME-Version: 1.0 References: <8CE29EA89CBA8F74C1D4D8EEF2528473@eigenstate.org> In-Reply-To: From: =?UTF-8?B?Sm9zw6kgTWlndWVsIFPDoW5jaGV6IEdhcmPDrWE=?= Date: Tue, 13 Jul 2021 12:27:17 +0200 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: RESTful plugin WEB2.0 replication-scale hardware Subject: Re: [9front] Mouse clipping patch Reply-To: 9front@9front.org Precedence: bulk There is none, but that's a different issue (it could be easily solved if rio provided an "uncurrent" key or an alt-tab-like key. I feel like that belongs to another patch). Unfocusing the window deactivates the grab, and I'm trying hard not to say release: the grab is still there, just doesn't apply if the window is not focused. Focus that window again and its grab will be applied again like nothing happened. On Tue, Jul 13, 2021 at 12:19 PM hiro <23hiro@gmail.com> wrote: > > 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=C3=A9 Miguel S=C3=A1nchez Garc=C3=ADa 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=C3=A9 Miguel S=C3=A1nchez Garc=C3=ADa : > >> > 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 =3D strtol(x->data+4, &p, 0); > >> > + if(p =3D=3D 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 =3D strtol(p, &e, 0); > >> if(p =3D=3D e || *e !=3D ' ') > >> // error > >> p =3D e; > >> > >> You can probably clean it up a bit with tokenize(), > >> and then ensure that *e =3D=3D '\0': > >> > >> if(tokenize(x->data+4, coords, 4) !=3D 4) > >> error() > >> n =3D strtol(coords[0], &e, 0); > >> if(*e !=3D 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? > >> > >