9front - general discussion about 9front
 help / color / mirror / Atom feed
* [9front] dangerous Exit menu item in sub-rio
@ 2022-08-18  5:34 Xiao-Yong Jin
  2022-08-18  5:44 ` B. Atticus Grobe
  2022-08-18  5:50 ` qwx
  0 siblings, 2 replies; 22+ messages in thread
From: Xiao-Yong Jin @ 2022-08-18  5:34 UTC (permalink / raw)
  To: 9front

Right click in sub-rio now becomes quite dangerous,
an accidental release of the right button when the
mouse cursor is on the Exit menu item will destroy
everything in that sub-rio.

Consider this, every other menu item in that list
requires you to use the mouse one more time to take
an effect, except this Exit.

The most dangerous item in the menu requires the least
effort to trigger.  Do we really need such convenience
in destroying sub-rio?  How often do you destroy the
sub-rios?  What's preventing using the parent rio's
Delete menu item for this?

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  2022-08-18  5:34 [9front] dangerous Exit menu item in sub-rio Xiao-Yong Jin
@ 2022-08-18  5:44 ` B. Atticus Grobe
  2022-08-18  5:50 ` qwx
  1 sibling, 0 replies; 22+ messages in thread
From: B. Atticus Grobe @ 2022-08-18  5:44 UTC (permalink / raw)
  To: 9front; +Cc: meta.jxy

There are plenty of good reasons for wanting to close a sub-rio, but
keep the window, for instance, to preserve the namespace you've built
there for testing or other reasons.

Having a confirmation of some sort was discussed and rejected. While the
other options require multiple clicks, that is because they require
further inputs. The Exit option does not. No other options require
confirmation beyond the necessary inputs for them to function.

I've been using a version of this that always has an Exit option in rio
since before it was merged, and haven't managed to click Exit accidentally
even once.

If its a problem for you, just patch your local rio.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  2022-08-18  5:34 [9front] dangerous Exit menu item in sub-rio Xiao-Yong Jin
  2022-08-18  5:44 ` B. Atticus Grobe
@ 2022-08-18  5:50 ` qwx
  2022-08-18  9:17   ` Steve Simon
  1 sibling, 1 reply; 22+ messages in thread
From: qwx @ 2022-08-18  5:50 UTC (permalink / raw)
  To: 9front

On Thu Aug 18 07:34:32 +0200 2022, meta.jxy@gmail.com wrote:
> Right click in sub-rio now becomes quite dangerous,
> an accidental release of the right button when the
> mouse cursor is on the Exit menu item will destroy
> everything in that sub-rio.

I agree and this had been the reason why it wasn't accepted in the
past, though it wasn't for subrios alone.  I strongly suggest adding a
confirm click or something if this is kept.


> The most dangerous item in the menu requires the least
> effort to trigger.  Do we really need such convenience
> in destroying sub-rio?  How often do you destroy the
> sub-rios?  What's preventing using the parent rio's
> Delete menu item for this?

I use subrios quite heavily and I need it *all of the time*.  In some
circumstances, one ends up having to find the subrio's pid and kill(1)
it, even within itself.  One silly example is a rio started while
rcpu(1)'d, same with vnc.  Others include scripts starting subrios and
cleaning up after themselves.  You can jump through hoops and
accomplish the same thing, but after years with it, I think Exit is
massively useful.  I do think that there should be some safeguard
mechanism though.

Cheers,
qwx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  2022-08-18  5:50 ` qwx
@ 2022-08-18  9:17   ` Steve Simon
  2022-08-18 10:48     ` Jacob Moody
  0 siblings, 1 reply; 22+ messages in thread
From: Steve Simon @ 2022-08-18  9:17 UTC (permalink / raw)
  To: 9front

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


> On 18 Aug 2022, at 07:51, qwx@sciops.net wrote:
> 
> On Thu Aug 18 07:34:32 +0200 2022, meta.jxy@gmail.com wrote:
>> Right click in sub-rio now becomes quite dangerous,
>> an accidental release of the right button when the
>> mouse cursor is on the Exit menu item will destroy
>> everything in that sub-rio.
> 
> I agree and this had been the reason why it wasn't accepted in the
> past, though it wasn't for subrios alone.  I strongly suggest adding a
> confirm click or something if this is kept.
> 
> 
>> The most dangerous item in the menu requires the least
>> effort to trigger.  Do we really need such convenience
>> in destroying sub-rio?  How often do you destroy the
>> sub-rios?  What's preventing using the parent rio's
>> Delete menu item for this?
> 
> I use subrios quite heavily and I need it *all of the time*.  In some
> circumstances, one ends up having to find the subrio's pid and kill(1)
> it, even within itself.  One silly example is a rio started while
> rcpu(1)'d, same with vnc.  Others include scripts starting subrios and
> cleaning up after themselves.  You can jump through hoops and
> accomplish the same thing, but after years with it, I think Exit is
> massively useful.  I do think that there should be some safeguard
> mechanism though.
> 
> Cheers,
> qwx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  2022-08-18  9:17   ` Steve Simon
@ 2022-08-18 10:48     ` Jacob Moody
  2022-08-18 11:46       ` Jacob Moody
  2022-08-18 13:46       ` igor
  0 siblings, 2 replies; 22+ messages in thread
From: Jacob Moody @ 2022-08-18 10:48 UTC (permalink / raw)
  To: 9front

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,
moody

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  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
  1 sibling, 1 reply; 22+ messages in thread
From: Jacob Moody @ 2022-08-18 11:46 UTC (permalink / raw)
  To: 9front

I have pushed the change. This now follows qwx's code
for providing a confirmation step similar to mothra.
The cursor used was recommended by umbraticus to be the
skill cursor from tweak.

May we take a moment of silence to mourn the subrios
killed prematurely in the interim.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  2022-08-18 11:46       ` Jacob Moody
@ 2022-08-18 11:56         ` qwx
  0 siblings, 0 replies; 22+ messages in thread
From: qwx @ 2022-08-18 11:56 UTC (permalink / raw)
  To: 9front

On Thu Aug 18 13:47:55 +0200 2022, moody@mail.posixcafe.org wrote:
> I have pushed the change. This now follows qwx's code
> for providing a confirmation step similar to mothra.
> The cursor used was recommended by umbraticus to be the
> skill cursor from tweak.
> 
> May we take a moment of silence to mourn the subrios
> killed prematurely in the interim.

Nice, thanks!

Cheers,
qwx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  2022-08-18 10:48     ` Jacob Moody
  2022-08-18 11:46       ` Jacob Moody
@ 2022-08-18 13:46       ` igor
  2022-08-18 13:51         ` ori
                           ` (2 more replies)
  1 sibling, 3 replies; 22+ messages in thread
From: igor @ 2022-08-18 13:46 UTC (permalink / raw)
  To: 9front

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


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  2022-08-18 13:46       ` igor
@ 2022-08-18 13:51         ` ori
  2022-08-18 13:59           ` Stanley Lieber
  2022-08-18 15:16         ` qwx
  2022-08-26  6:48         ` mkf9
  2 siblings, 1 reply; 22+ messages in thread
From: ori @ 2022-08-18 13:51 UTC (permalink / raw)
  To: 9front

Quoth igor@9lab.org:
> 
> 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.

I think I like that.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  2022-08-18 13:51         ` ori
@ 2022-08-18 13:59           ` Stanley Lieber
  2022-08-18 15:52             ` igor
  2022-08-18 15:59             ` Jacob Moody
  0 siblings, 2 replies; 22+ messages in thread
From: Stanley Lieber @ 2022-08-18 13:59 UTC (permalink / raw)
  To: 9front

what if the gray background is completely covered up?

maybe exit could imitate delete and just require a second click (but this time, click anywhere and the current rio dies). we don’t have to call it a confirmation, we can pretend we’re a hunter targeting our prey. we could even borrow the skull and crossbones icon from mothra. maybe this would disturb the cognitive load just enough to be effective?

sl


> On Aug 18, 2022, at 9:51 AM, ori@eigenstate.org wrote:
> 
> Quoth igor@9lab.org:
>> 
>> 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.
> 
> I think I like that.
> 
> 


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  2022-08-18 13:46       ` igor
  2022-08-18 13:51         ` ori
@ 2022-08-18 15:16         ` qwx
  2022-08-26  6:48         ` mkf9
  2 siblings, 0 replies; 22+ messages in thread
From: qwx @ 2022-08-18 15:16 UTC (permalink / raw)
  To: 9front

I know I'm in the minority, but *imho* Rob's opinion here is bullshit.
With the latest change this also already is a two-step process, and
for me personally the Delete idea won't work [1].  But that's like, my
opinion man, and I'm probably not the best example.

Cheers,
qwx

[1] http://nopenopenope.net/up/riowhat.png
(boxrios in mailrio in vncrio)

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  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
  1 sibling, 1 reply; 22+ messages in thread
From: igor @ 2022-08-18 15:52 UTC (permalink / raw)
  To: 9front

Quoth Stanley Lieber <sl@stanleylieber.com>:
> what if the gray background is completely covered up?

Maybe I am doing something wrong but if the gray background
is completely covered I can not even bring the rio menu
that allows me to say `New`, `Delete`, etc.

Even if there is a way to bring up the menu when the
grey is covered up, isn't this similar to the case where
the window you want to `Delete` is hidden?

In that case you would bring the window to the front,
select `Delete`, and then select the window you just
brought to the front for deletion.

When the sub-rio you want to `Delete` isn't visible
because it is covered up, you need to make it visible,
select `Delete`, and then select the gray of the sub
rio.

That being said, I think there is agreement that the
process of Exit from a sub-rio should be a two step
process. Either select Exit and Confirm, or use the
semantics with `Delete` where the second step is selecting
the gray from the sub-rio as the target of the `Delete,
obviating the need for an additional menu entry.

My personal taste is for `Delete`, but the other options
is just as workable, no complaints.


> 
> maybe exit could imitate delete and just require a second click (but this time, click anywhere and the current rio dies). we don’t have to call it a confirmation, we can pretend we’re a hunter targeting our prey. we could even borrow the skull and crossbones icon from mothra. maybe this would disturb the cognitive load just enough to be effective?
> 
> sl
> 
> 
> > On Aug 18, 2022, at 9:51 AM, ori@eigenstate.org wrote:
> > 
> > Quoth igor@9lab.org:
> >> 
> >> 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.
> > 
> > I think I like that.
> > 
> > 
> 


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  2022-08-18 13:59           ` Stanley Lieber
  2022-08-18 15:52             ` igor
@ 2022-08-18 15:59             ` Jacob Moody
  2022-08-18 16:18               ` Stanley Lieber
                                 ` (3 more replies)
  1 sibling, 4 replies; 22+ messages in thread
From: Jacob Moody @ 2022-08-18 15:59 UTC (permalink / raw)
  To: 9front

On 8/18/22 07:59, Stanley Lieber wrote:
> what if the gray background is completely covered up?
> 
> maybe exit could imitate delete and just require a second click (but this time, click anywhere and the current rio dies). we don’t have to call it a confirmation, we can pretend we’re a hunter targeting our prey. we could even borrow the skull and crossbones icon from mothra. maybe this would disturb the cognitive load just enough to be effective?
> 
> sl

This is exactly how it works now, following the latest commit made this morning.

Thanks,

moody

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  2022-08-18 15:59             ` Jacob Moody
@ 2022-08-18 16:18               ` Stanley Lieber
  2022-08-18 16:22               ` Kurt H Maier
                                 ` (2 subsequent siblings)
  3 siblings, 0 replies; 22+ messages in thread
From: Stanley Lieber @ 2022-08-18 16:18 UTC (permalink / raw)
  To: 9front

uh, carry on!

sl

> On Aug 18, 2022, at 12:02 PM, Jacob Moody <moody@mail.posixcafe.org> wrote:
> 
> On 8/18/22 07:59, Stanley Lieber wrote:
>> what if the gray background is completely covered up?
>> 
>> maybe exit could imitate delete and just require a second click (but this time, click anywhere and the current rio dies). we don’t have to call it a confirmation, we can pretend we’re a hunter targeting our prey. we could even borrow the skull and crossbones icon from mothra. maybe this would disturb the cognitive load just enough to be effective?
>> 
>> sl
> 
> This is exactly how it works now, following the latest commit made this morning.
> 
> Thanks,
> 
> moody
> 


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  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 21:53                 ` the lemons
  2022-08-18 16:43               ` kvik
  2022-08-18 22:30               ` Stuart Morrow
  3 siblings, 2 replies; 22+ messages in thread
From: Kurt H Maier @ 2022-08-18 16:22 UTC (permalink / raw)
  To: 9front

On Thu, Aug 18, 2022 at 09:59:40AM -0600, Jacob Moody wrote:
> On 8/18/22 07:59, Stanley Lieber wrote:
> > what if the gray background is completely covered up?
> > 
> > maybe exit could imitate delete and just require a second click (but this time, click anywhere and the current rio dies). we don’t have to call it a confirmation, we can pretend we’re a hunter targeting our prey. we could even borrow the skull and crossbones icon from mothra. maybe this would disturb the cognitive load just enough to be effective?
> > 
> > sl
> 
> This is exactly how it works now, following the latest commit made this morning.
> 
> Thanks,
> 
> moody


Awful.  Terrible.  Clicking exit should result in a modal dialog
confirmation box, and upon confirmation should shitcan all running
processes in the subrio, black out the screen, and print "It Is Now Safe
To Turn Off Your Rio" in huge orange letters.  The market has spoken.

khm

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  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:43               ` kvik
  2022-08-18 22:30               ` Stuart Morrow
  3 siblings, 0 replies; 22+ messages in thread
From: kvik @ 2022-08-18 16:43 UTC (permalink / raw)
  To: 9front

Using rio is an intrinsically dangerous activity. Let's add an -Exit flag to quit before it has a chance to start.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  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
  1 sibling, 1 reply; 22+ messages in thread
From: Frank D. Engel, Jr. @ 2022-08-18 16:57 UTC (permalink / raw)
  To: 9front

Why not move the confirmation to be first - so that the user needs to 
confirm that they even want the option to exit before it shows up in the 
menu?

Or else have the option there but disabled unless a modifier key is held 
down on the keyboard (hold down shift or whatever to enable the exit item)?


On 8/18/22 12:22 PM, Kurt H Maier wrote:
> On Thu, Aug 18, 2022 at 09:59:40AM -0600, Jacob Moody wrote:
>> On 8/18/22 07:59, Stanley Lieber wrote:
>>> what if the gray background is completely covered up?
>>>
>>> maybe exit could imitate delete and just require a second click (but this time, click anywhere and the current rio dies). we don’t have to call it a confirmation, we can pretend we’re a hunter targeting our prey. we could even borrow the skull and crossbones icon from mothra. maybe this would disturb the cognitive load just enough to be effective?
>>>
>>> sl
>> This is exactly how it works now, following the latest commit made this morning.
>>
>> Thanks,
>>
>> moody
>
> Awful.  Terrible.  Clicking exit should result in a modal dialog
> confirmation box, and upon confirmation should shitcan all running
> processes in the subrio, black out the screen, and print "It Is Now Safe
> To Turn Off Your Rio" in huge orange letters.  The market has spoken.
>
> khm
>


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  2022-08-18 16:57                 ` Frank D. Engel, Jr.
@ 2022-08-18 17:02                   ` Stanley Lieber
  0 siblings, 0 replies; 22+ messages in thread
From: Stanley Lieber @ 2022-08-18 17:02 UTC (permalink / raw)
  To: 9front

config file for the exit button?

not for the menu, but the actual exit item itself.

sl


> On Aug 18, 2022, at 12:58 PM, Frank D. Engel, Jr. <fde101@fjrhome.net> wrote:
> 
> Why not move the confirmation to be first - so that the user needs to confirm that they even want the option to exit before it shows up in the menu?
> 
> Or else have the option there but disabled unless a modifier key is held down on the keyboard (hold down shift or whatever to enable the exit item)?
> 
> 
>> On 8/18/22 12:22 PM, Kurt H Maier wrote:
>>> On Thu, Aug 18, 2022 at 09:59:40AM -0600, Jacob Moody wrote:
>>> On 8/18/22 07:59, Stanley Lieber wrote:
>>>> what if the gray background is completely covered up?
>>>> 
>>>> maybe exit could imitate delete and just require a second click (but this time, click anywhere and the current rio dies). we don’t have to call it a confirmation, we can pretend we’re a hunter targeting our prey. we could even borrow the skull and crossbones icon from mothra. maybe this would disturb the cognitive load just enough to be effective?
>>>> 
>>>> sl
>>> This is exactly how it works now, following the latest commit made this morning.
>>> 
>>> Thanks,
>>> 
>>> moody
>> 
>> Awful.  Terrible.  Clicking exit should result in a modal dialog
>> confirmation box, and upon confirmation should shitcan all running
>> processes in the subrio, black out the screen, and print "It Is Now Safe
>> To Turn Off Your Rio" in huge orange letters.  The market has spoken.
>> 
>> khm
>> 
> 
> 


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  2022-08-18 16:22               ` Kurt H Maier
  2022-08-18 16:57                 ` Frank D. Engel, Jr.
@ 2022-08-18 21:53                 ` the lemons
  1 sibling, 0 replies; 22+ messages in thread
From: the lemons @ 2022-08-18 21:53 UTC (permalink / raw)
  To: 9front

On Thu Aug 18, 2022 at 11:22 AM CDT, Kurt H Maier wrote:
> Awful.  Terrible.  Clicking exit should result in a modal dialog
> confirmation box, and upon confirmation should shitcan all running
> processes in the subrio, black out the screen, and print "It Is Now Safe
> To Turn Off Your Rio" in huge orange letters.  The market has spoken.

don't forget to fade the screen behind that confirmation box to black
and white!

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  2022-08-18 15:59             ` Jacob Moody
                                 ` (2 preceding siblings ...)
  2022-08-18 16:43               ` kvik
@ 2022-08-18 22:30               ` Stuart Morrow
  3 siblings, 0 replies; 22+ messages in thread
From: Stuart Morrow @ 2022-08-18 22:30 UTC (permalink / raw)
  To: 9front

On 18/08/2022, Jacob Moody <moody@mail.posixcafe.org> wrote:
> On 8/18/22 07:59, Stanley Lieber wrote:
>> maybe exit could imitate delete and just require a second click (but this
>> time, click anywhere and the current rio dies)
> This is exactly how it works now, following the latest commit made this
> morning.

Bikeshed post, but Mothra's icon has no-no-yes, referring to the mouse
buttons in that order,
and Rio's doesn't.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  2022-08-18 15:52             ` igor
@ 2022-08-18 22:33               ` Stuart Morrow
  0 siblings, 0 replies; 22+ messages in thread
From: Stuart Morrow @ 2022-08-18 22:33 UTC (permalink / raw)
  To: 9front

On 18/08/2022, igor@9lab.org <igor@9lab.org> wrote:
> Maybe I am doing something wrong but if the gray background
> is completely covered I can not even bring the rio menu
> that allows me to say `New`, `Delete`, etc.

Uh, right-click in any window that doesn't eat the mouse...

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [9front] dangerous Exit menu item in sub-rio
  2022-08-18 13:46       ` igor
  2022-08-18 13:51         ` ori
  2022-08-18 15:16         ` qwx
@ 2022-08-26  6:48         ` mkf9
  2 siblings, 0 replies; 22+ messages in thread
From: mkf9 @ 2022-08-26  6:48 UTC (permalink / raw)
  To: 9front

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
> 


^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2022-08-26  6:52 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-18  5:34 [9front] dangerous Exit menu item in sub-rio 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 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).