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?
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.
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
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
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
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.
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
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
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.
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.
>
>
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)
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. > > > > >
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
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
>
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
Using rio is an intrinsically dangerous activity. Let's add an -Exit flag to quit before it has a chance to start.
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
>
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
>>
>
>
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!
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.
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...
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
>