Operator Confirmation Configuration #106870

New Issue

Harley Acheson · 2023-04-12T17:58:27+02:00

Harley Acheson commented

2023-04-12 17:58:27 +02:00

Note that this is not about the code that creates the confirmations (I have another proposal for that, #106691).

Background

Some operators ask a user to confirm their intentions before they proceed, as a safety measure when the operation could cause unintended damage. A simple example is the "OK?" you get when deleting an object by pressing the "x" key. The fact that doing so by pressing "Delete" instead does not warn is integral to this proposal.

Some of these operators define a property called "confirm". OBJECT_OT_delete then uses an "invoke" callback called WM_operator_confirm_or_exec that checks this property and, if set, will show the confirmation message.

In the keymap editor we see this property as a "Confirm" checkmark. In this case "X" has it enabled and "Delete" has it disabled. We usually justify this difference because the "delete" key is nicely separated from other keys while "x" can more easily be hit accidentally.

Immediate Issues

The Modelling module has brought up that some operators have confirmations that cannot be configured. These are mostly operators that have their "invoke" callback set to WM_operator_confirm. That function does not check for a "confirm" property and so asks for confirmation every time and cannot be turned off in the keymap. These include "delete keyframe", "delete bone", "delete curve", "delete track", "delete marker", "separate bones", "separate curves", "delete mask", "make vertex parent", etc.

A simple solution to this is to simply fix the operators as needed. Each can call WM_operator_properties_confirm_or_exec to add the "confirm" property, and then use WM_operator_confirm_or_exec for "invoke" instead of WM_operator_confirm. This would then allow these confirmations to be turned off in the keymaps.

Proposed Solution

I don't think these should be configured in the keymap. Most users would find it very difficult to do so. And it doesn't seem to fit this kind of preference. If I desire a warning about an operation it is about the operation itself and not the way it was launched.

I think we should abandon the use of having an operator "confirm" property and instead move this configuration to a new section of user Preferences. I think we should have a new "Warnings" section with checkmarks to allow quickly enabling and disabling.

It is worth considering making this more than just a binary choice. For example, it might be nice if OBJECT_OT_delete could allow a choice between "Never", "Always", and "When more than one selected".

Longer Term

Ultimately, I would prefer that more operators have optional confirmations, disabled by default. That is the reason for #106691. And have a fairly large "Warning" Preferences section that allows users to make Blender suit their needs. I think we should use our best judgement to set the defaults for these, but I would prefer to allow users to do things that we don't like. Allow them have no warnings at all or be nagged for every little thing. We are all different and it would be nice to allow for these differences.

Note that this is not about the code that creates the confirmations (I have another proposal for that, #106691). **Background** Some operators ask a user to confirm their intentions before they proceed, as a safety measure when the operation could cause unintended damage. A simple example is the "OK?" you get when deleting an object by pressing the "x" key. The fact that doing so by pressing "Delete" instead does not warn is integral to this proposal. Some of these operators define a property called "confirm". `OBJECT_OT_delete` then uses an "invoke" callback called `WM_operator_confirm_or_exec` that checks this property and, if set, will show the confirmation message. In the keymap editor we see this property as a "Confirm" checkmark. In this case "X" has it enabled and "Delete" has it disabled. We usually justify this difference because the "delete" key is nicely separated from other keys while "x" can more easily be hit accidentally. **Immediate Issues** The Modelling module has brought up that some operators have confirmations that cannot be configured. These are mostly operators that have their "invoke" callback set to `WM_operator_confirm`. That function does not check for a "confirm" property and so asks for confirmation every time and cannot be turned off in the keymap. These include "delete keyframe", "delete bone", "delete curve", "delete track", "delete marker", "separate bones", "separate curves", "delete mask", "make vertex parent", etc. A simple solution to this is to simply fix the operators as needed. Each can call `WM_operator_properties_confirm_or_exec` to add the "confirm" property, and then use `WM_operator_confirm_or_exec` for "invoke" instead of `WM_operator_confirm`. This would then allow these confirmations to be turned off in the keymaps. **Proposed Solution** I don't think these should be configured in the keymap. Most users would find it very difficult to do so. And it doesn't seem to fit this kind of preference. If I desire a warning about an operation it is about the _operation itself_ and not the way it was launched. I think we should abandon the use of having an operator "confirm" property and instead move this configuration to a new section of user Preferences. I think we should have a new "Warnings" section with checkmarks to allow quickly enabling and disabling. It is worth considering making this more than just a binary choice. For example, it might be nice if `OBJECT_OT_delete` could allow a choice between "Never", "Always", and "When more than one selected". **Longer Term** Ultimately, I would prefer that more operators have optional confirmations, disabled by default. That is the reason for #106691. And have a fairly large "Warning" Preferences section that allows users to make Blender suit their needs. I think we should use our best judgement to set the defaults for these, but I would prefer to allow users to do things that we don't like. Allow them have no warnings at all or be nagged for every little thing. We are all different and it would be nice to allow for these differences.

👍 1 ❤️ 3

Harley Acheson added the

Type

Design

label 2023-04-12 17:58:27 +02:00

Harley Acheson added this to the User Interface project 2023-04-12 17:58:28 +02:00

Paul Kotelevets commented

2023-04-14 12:09:58 +02:00

I would like also have file save confirmation menu which shows the entire path as an option, which is very useful when you work with lots of versions of the same files opened from different places (HDD, flashdrive, server, temp, backups).

Also such a mechanics provide nice visual feedback so you don't have to Ctrl+S Ctrl+S Ctrl+S all the time to make sure you press the buttons hard enough for your file to be saved.
Flashing message in the status bar helps a lot, in case of a single monitor which is hot huge.

I would like also have file save confirmation menu which shows the entire path as an option, which is very useful when you work with lots of versions of the same files opened from different places (HDD, flashdrive, server, temp, backups). Also such a mechanics provide nice visual feedback so you don't have to Ctrl+S Ctrl+S Ctrl+S all the time to make sure you press the buttons hard enough for your file to be saved. Flashing message in the status bar helps a lot, in case of a single monitor which is hot huge.

Brad Clark commented

2023-04-18 22:56:53 +02:00

Thank you and love all this!

Harley Acheson referenced this issue

2024-03-01 00:06:42 +01:00

Roadmap #118940

Sign in to join this conversation.