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 16281 invoked from network); 18 Aug 2022 13:48:32 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 18 Aug 2022 13:48:32 -0000 Received: from mail.9lab.org ([168.119.8.41]) by 9front; Thu Aug 18 09:46:18 -0400 2022 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=9lab.org; s=20210803; t=1660830371; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to; bh=hE7zyiHo1ERrWP/zWDWJzWTt1t2onGyNO5K9VknVfqE=; b=QjO30eQndG/7tD5QP/XOw6dQhpmTG1vE9QRapJYlrjpbQ3N+twZFo5chsbsEC+9YmtUcn0 TTrITnFq3LeHxlHKLX8uDjBe07VuYZJdZ4Nl/U6RigouJGZqEyX+bTOolzc8D0pXlhRJfK MgKnt+XauEmpDt5FrdJ1v7+p8x/6B10= Received: from rob.9lab.home (host-185-64-155-70.ecsnet.at [185.64.155.70]) by mail.9lab.org (OpenSMTPD) with ESMTPSA id bfd0595d (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO) for <9front@9front.org>; Thu, 18 Aug 2022 15:46:11 +0200 (CEST) Message-ID: To: 9front@9front.org Date: Thu, 18 Aug 2022 15:46:10 +0200 From: igor@9lab.org In-Reply-To: <327fe199-bb38-c988-9514-5b6a8278fcb2@posixcafe.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: optimized factory hosting realtime-java-oriented extension Subject: Re: [9front] dangerous Exit menu item in sub-rio Reply-To: 9front@9front.org Precedence: bulk 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’n crossbones if Exit was selected - to indicate another B1 click was 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 survey > and the leading idea seemed to just be to have it exit. I think some of > this comes down to how you use subrios. For how I use them, a premature > exit would not ruin my morning. But I can very much imagine someone having > 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 subrios > would prefer to have a confirmation exit step. For those that don't, one > more mouse click is not a painful compromise. […] 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: ``Mux doesn’t ask for confirmation to do risky things. It always 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 ‘click, click’ instead of ‘click, read the message, think about it, click.'' Note how Pike argues that confirmations don't work, however, dangerous operations like `Delete` are a two step process. 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. Consider a menu that looks something like this: New Move Resize Delete Hide Exit Window1 Window2 Window3 ... WindowN 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. 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. Another option is to move `Exit` to the very bottom, below all the windows, e.g.: New Move Resize Delete Hide Window1 Window2 Window3 ... WindowN Exit That way one is less likely to click `Exit` when trying to `Hide` or select a window. 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. Cheers, Igor