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.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 12309 invoked from network); 26 Aug 2022 06:52:18 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 26 Aug 2022 06:52:18 -0000 Received: from mx1.riseup.net ([198.252.153.129]) by 9front; Fri Aug 26 02:48:21 -0400 2022 Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.riseup.net", Issuer "R3" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4MDVlh6bTGzDqLh for <9front@9front.org>; Fri, 26 Aug 2022 06:48:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1661496497; bh=9ueEEQmFh3jNhTs7HDRKcNapWn8p+2orBNExUAzA8wI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=HIdE5KPzd3gRvNcGPLdTAY8m8Kpf/Ptp2qMkyijrPFprxq4oMK7aH9iMR1Be9bo2j 0ZuAQVXyJQl9cgOBMzIip6mIY9zhfDv3NsBQTDLbZVkIKXRwSCd07dg5wveRbWCQJ7 IP5K7LEkoS5Yol/z2gmcvB5jBlkS/0ahTbx5xAUo= X-Riseup-User-ID: EF71BC79E2BCF3DE340D538713EC6E501116ED9638AB54431521D80E2DE85E7B Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4MDVlh1THvz5vNH for <9front@9front.org>; Fri, 26 Aug 2022 06:48:15 +0000 (UTC) To: 9front@9front.org References: From: mkf9 Message-ID: Date: Fri, 26 Aug 2022 11:18:09 +0430 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: realtime-java metadata CMS descriptor realtime rails Subject: Re: [9front] dangerous Exit menu item in sub-rio Reply-To: 9front@9front.org Precedence: bulk How can you be sure "Exit" in the end isn't some real window? in case you have maximized your subrio and not sure if it's mainrio or subrio. % label Exit igor@9lab.org wrote: > Quoth Jacob Moody : >> On 8/18/22 03:17, Steve Simon wrote: >>> maybe it still has, but mothra used to switch its cursor to a skull=E2= =80=99n crossbones if Exit was selected - to indicate another B1 click wa= s needed to confirm the exit, any other mouse button to cancel the exit. >>> >>> -Steve >> >> Yes mothra still has this behavior. I am not opposed to adding >> a confirmation step. When the first patch was discussed I took a surve= y >> and the leading idea seemed to just be to have it exit. I think some o= f >> this comes down to how you use subrios. For how I use them, a prematur= e >> exit would not ruin my morning. But I can very much imagine someone ha= ving >> a workflow where that would be quite the damper on their morning. >> >> It seems to me that people that get quite a bit of mileage out of subr= ios >> would prefer to have a confirmation exit step. For those that don't, o= ne >> more mouse click is not a painful compromise. > [=E2=80=A6] >=20 > Thanks for the option to `Exit` a sub-rio. The comment about a > confirmation before exiting made me remeber the `Window Systems Should > Be Transparent` [1] paper by Rob Pike where he asserts that > ``confirmations don't work'', here the relevant section: >=20 > ``Mux doesn=E2=80=99t ask for confirmation to do risky things. It alwa= ys does > what the user asks. The most obvious case is deleting a window. The > protocol for deleting a window is a two-step process: select Delete, > then indicate which window. The action can be aborted before picking > the window, so there is an element of safety built in; selecting > Delete does not immediately endanger any window. This is one reason > why a window must be selected by a button click rather than just by > the position of the mouse. Once in a while a window is accidentally > deleted, but this will happen whatever precautions are taken, and the > pain of recovering it must be weighed against the bother of dealing > with a complicated protocol for deletion. (Presumably software has > some safeguards; editors will save their contents, for example.) > Confirmations are ignored in practice. Once a user is at all familiar > with a system, the confirmations are executed without thinking about > them; the act of deletion becomes =E2=80=98click, click=E2=80=99 instea= d of =E2=80=98click, > read the message, think about it, click.'' >=20 > Note how Pike argues that confirmations don't work, however, > dangerous operations like `Delete` are a two step process. >=20 > I have accidentally `Exit`ed from sub-rio and unfortunately it > does keep happening and I think one reason is because `Exit' > is *not* a two-step process, another reason might be because > `Exit' might be buried in the menu when many windows are opened. >=20 > Consider a menu that looks something like this: >=20 > New > Move > Resize > Delete > Hide > Exit > Window1 > Window2 > Window3 > ... > WindowN >=20 > Because `Exit` is buried somewhere in the middle, trying to select > `Window1` or `Hide` sometimes results in accidentally selecting > `Exit`, exiting a sub-rio with many windows. >=20 > Why does `Delete` not apply to a sub-rio, i.e., why does selecting > `Delete` and then clicking on the gray background of sub-rio not close > the sub-rio? That way it would remain a two-step process and there > is no need to add another menu option. >=20 > Another option is to move `Exit` to the very bottom, below all the > windows, e.g.: >=20 > New > Move > Resize > Delete > Hide > Window1 > Window2 > Window3 > ... > WindowN > Exit >=20 > That way one is less likely to click `Exit` when trying to `Hide` or > select a window. >=20 > While typing this email I believe moody mentioned to have implemented > a confirmation step similar to mothra. That is indeed another option > and one that most people are familiar with as well. >=20 > Cheers, > Igor >=20