9front - general discussion about 9front
 help / color / mirror / Atom feed
From: igor@9lab.org
To: 9front@9front.org
Subject: Re: [9front] dangerous Exit menu item in sub-rio
Date: Thu, 18 Aug 2022 15:46:10 +0200	[thread overview]
Message-ID: <CE8250A802E30C022AA6E0F676E69D2D@9lab.org> (raw)
In-Reply-To: <327fe199-bb38-c988-9514-5b6a8278fcb2@posixcafe.org>

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


  parent reply	other threads:[~2022-08-18 13:48 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 [this message]
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

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=CE8250A802E30C022AA6E0F676E69D2D@9lab.org \
    --to=igor@9lab.org \
    --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).