From: mkf9 <mkf9@riseup.net>
To: 9front@9front.org
Subject: Re: [9front] dangerous Exit menu item in sub-rio
Date: Fri, 26 Aug 2022 11:18:09 +0430 [thread overview]
Message-ID: <b4137ef7-5958-4caa-7d47-9e8d97fafa1b@riseup.net> (raw)
In-Reply-To: <CE8250A802E30C022AA6E0F676E69D2D@9lab.org>
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 <moody@mail.posixcafe.org>:
>> 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
>
prev parent reply other threads:[~2022-08-26 6:52 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-18 5:34 Xiao-Yong Jin
2022-08-18 5:44 ` B. Atticus Grobe
2022-08-18 5:50 ` qwx
2022-08-18 9:17 ` Steve Simon
2022-08-18 10:48 ` Jacob Moody
2022-08-18 11:46 ` Jacob Moody
2022-08-18 11:56 ` qwx
2022-08-18 13:46 ` igor
2022-08-18 13:51 ` ori
2022-08-18 13:59 ` Stanley Lieber
2022-08-18 15:52 ` igor
2022-08-18 22:33 ` Stuart Morrow
2022-08-18 15:59 ` Jacob Moody
2022-08-18 16:18 ` Stanley Lieber
2022-08-18 16:22 ` Kurt H Maier
2022-08-18 16:57 ` Frank D. Engel, Jr.
2022-08-18 17:02 ` Stanley Lieber
2022-08-18 21:53 ` the lemons
2022-08-18 16:43 ` kvik
2022-08-18 22:30 ` Stuart Morrow
2022-08-18 15:16 ` qwx
2022-08-26 6:48 ` mkf9 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b4137ef7-5958-4caa-7d47-9e8d97fafa1b@riseup.net \
--to=mkf9@riseup.net \
--cc=9front@9front.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).