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 29531 invoked from network); 13 Jul 2021 03:21:17 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 13 Jul 2021 03:21:17 -0000 Received: from mail-pf1-f180.google.com ([209.85.210.180]) by 1ess; Mon Jul 12 23:14:59 -0400 2021 Received: by mail-pf1-f180.google.com with SMTP id y4so18244288pfi.9 for <9front@9front.org>; Mon, 12 Jul 2021 20:14:53 -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=96i25rNPZUQLKJWSGlWEfhwAxkYYYAmROQkWoTuPcO0=; b=pHD1OBcweaRA6KIdn6LrJJoeV8av4jZTelREWntuA/3Ra96AD4PbEwvqiiVCiqgKUG rdHJ9Bd6OOUOEzcZnqxdCHaDbuJQeB5ftpRafS39WhvRH6vI6uu12EPRKotJvV0/sR+v pHaj13taQ+hPwgnnLymqdpLyBvnnK1RlfNpxQML95wphgKmTPZwaILsu++tcq9qlBYdg ujYPihEUOPgJk+tdLnpCodRTgdSjzShjbwsGekQiKM7VjIPWR+VHRlELmnmQIOZ9pMpt Cenau0K4MituXbICU8/gTljJ74OEGD+IVctWSK0wtxy+SXi7v8Qf11gxmtkm/hxna1mp BrtA== 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=96i25rNPZUQLKJWSGlWEfhwAxkYYYAmROQkWoTuPcO0=; b=jzmr3Ci1iXWtMSnOoyxscDkBg3y19cP5dA1blHcuuY16t7qrDXEtM3DvJmeJ4s18nd I76rsEc4fs0xQJc2LEPeTtV7XA+bN56O0sbx/Q/lPlDD/vbyCCMZYTwK8UzqsX5bUTxO 9QA0wWWDXWMEntE7ERerh9WuVehEzspwhDWflhU/usiJ5JsG9VjmBL51aX82GOo3crNu eahC9VaSCEVe64NJy9UbCMJd1wFykGowaPyD7Pjf8yLeyivRTIVp+4f13XwmeNRqu0xM 3xtW6BmIWmbs/NQegp5CUm6ASEEsQX88iIQefHKgrbRvMJLV8f6qV4CWvWogngHeH/jg gVmg== X-Gm-Message-State: AOAM530W8aQzQR2KEaNZQYHGglLg34VEwsng4UiMp8TVWr+bVBj6AyRS W4ePvHzekWLerYvhwxdHC4+mOfX91OLMEhUKck3YdYkG5Oc= X-Google-Smtp-Source: ABdhPJzwrlq8YJ+E3/8m4NBL0D+Np9dKdKJN2oT+eDsh88LcZFdtEHhFp0mCwUfdOkf6pFYDWOrgsdUbU5V3gM+KjmU= X-Received: by 2002:a63:ff22:: with SMTP id k34mr2217936pgi.336.1626146092339; Mon, 12 Jul 2021 20:14:52 -0700 (PDT) MIME-Version: 1.0 References: <8CE29EA89CBA8F74C1D4D8EEF2528473@eigenstate.org> In-Reply-To: <8CE29EA89CBA8F74C1D4D8EEF2528473@eigenstate.org> From: =?UTF-8?B?Sm9zw6kgTWlndWVsIFPDoW5jaGV6IEdhcmPDrWE=?= Date: Tue, 13 Jul 2021 05:14:40 +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: ActivityPub over TOR replication realtime-scale realtime-java layer Subject: Re: [9front] Mouse clipping patch Reply-To: 9front@9front.org Precedence: bulk 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? >