Anim: Detailed report if no keyframes have been inserted #119201

Merged
Christoph Lendenfeld merged 13 commits from ChrisLend/blender:return_keying_result into main 2024-04-09 09:39:25 +02:00

With this PR, when pressing I in the viewport and the code
is unable to insert ANY keyframes, the user will be presented
with a single message detailing exactly why it has failed.

This PR promotes the functionality introduced in
#117449: Refactor: keyframing functions return more detailed status
into the header file so it can be used elsewhere.

The CombinedKeyingResult class is returned
from insert_key_action and insert_key_rna, and
used to produce a single report from the operator if it
failed to insert any keyframes.

In order to easily create a report from a CombinedKeyingResult
the function generate_keyframe_reports_from_result
has been moved into the class as generate_reports.

In addition to that the UNABLE_TO_INSERT_TO_NLA_STACK result
has been added. This notifies the user if keyframe insertion is not
possible due to NLA stack settings.

With this PR, when pressing `I` in the viewport and the code is unable to insert **ANY** keyframes, the user will be presented with a single message detailing exactly why it has failed. This PR promotes the functionality introduced in [#117449: Refactor: keyframing functions return more detailed status](https://projects.blender.org/blender/blender/pulls/117449) into the header file so it can be used elsewhere. The `CombinedKeyingResult` class is returned from `insert_key_action` and `insert_key_rna`, and used to produce a single report from the operator if it failed to insert any keyframes. In order to easily create a report from a `CombinedKeyingResult` the function `generate_keyframe_reports_from_result` has been moved into the class as `generate_reports`. In addition to that the `UNABLE_TO_INSERT_TO_NLA_STACK` result has been added. This notifies the user if keyframe insertion is not possible due to NLA stack settings.
Christoph Lendenfeld added the
Module
Animation & Rigging
label 2024-03-08 12:34:04 +01:00
Christoph Lendenfeld added 2 commits 2024-03-08 12:34:14 +01:00
Christoph Lendenfeld changed title from WIP: Anim: Detailled report if no keyframes have been inserted to WIP: Anim: Detailed report if no keyframes have been inserted 2024-03-08 12:34:24 +01:00
Christoph Lendenfeld changed title from WIP: Anim: Detailed report if no keyframes have been inserted to Anim: Detailed report if no keyframes have been inserted 2024-03-08 12:45:03 +01:00
Christoph Lendenfeld added 1 commit 2024-03-08 14:03:33 +01:00
Christoph Lendenfeld added 1 commit 2024-03-08 14:46:17 +01:00
buildbot/vexp-code-patch-lint Build done. Details
buildbot/vexp-code-patch-linux-x86_64 Build done. Details
buildbot/vexp-code-patch-darwin-arm64 Build done. Details
buildbot/vexp-code-patch-darwin-x86_64 Build done. Details
buildbot/vexp-code-patch-windows-amd64 Build done. Details
buildbot/vexp-code-patch-coordinator Build done. Details
f7f40eac04
Merge branch 'main' into return_keying_result
Author
Member

@blender-bot build

@blender-bot build
Sybren A. Stüvel requested review from Sybren A. Stüvel 2024-03-22 12:20:46 +01:00
Sybren A. Stüvel added this to the 4.2 LTS milestone 2024-03-22 12:20:49 +01:00
Sybren A. Stüvel requested changes 2024-03-22 12:50:00 +01:00
Dismissed
@ -196,3 +232,3 @@
* \param keying_mask is expected to have the same size as `rna_path`. A false bit means that index
* will be skipped.
* \returns The number of keys inserted.
* \returns How often keyframe insertion was successful how often it failed for which reason.

How often keyframe insertion was successful and how often it failed / for which reason.

Same for the copies below, of course.

How often keyframe insertion was successful `and` how often it failed `/` for which reason. Same for the copies below, of course.
@ -85,0 +75,4 @@
{
/* For loop starts at 1 to skip the SUCCESS flag. Assumes that SUCCESS is 0 and the rest of the
* enum are sequential values. */
for (int i = 1; i < result_counter.size(); i++) {

For a future improvement: adding a static_assert(SingleKeyingResult::SUCCESS == 0) could be a nice touch here.

For a future improvement: adding a `static_assert(SingleKeyingResult::SUCCESS == 0)` could be a nice touch here.
Author
Member

decided to do that right away, imo this makes it more obvious what the code is expecting

decided to do that right away, imo this makes it more obvious what the code is expecting
@ -89,0 +83,4 @@
return false;
}
void CombinedKeyingResult::generate_reports(ReportList *reports)

Below this code is called when get_count(animrig::SingleKeyingResult::SUCCESS) == 0. However, this function does not take that case into account. The success count could theoretically be zero because nothing happened, in which case the generated report will end with "due to the following reasons:", which will be rather strange.

It's probably best to have a bool has_reported_error that's set to true in each specific if (error count > 0) block. That way you can check at the bottom of the function and, if it's false, add a report that explains the situation. That will ensure that something is shown, even when a configuration occurs that isn't (yet) supported by this function.

Below this code is called when `get_count(animrig::SingleKeyingResult::SUCCESS) == 0`. However, this function does not take that case into account. The success count could theoretically be zero because nothing happened, in which case the generated report will end with "due to the following reasons:", which will be rather strange. It's probably best to have a `bool has_reported_error` that's set to `true` in each specific `if (error count > 0)` block. That way you can check at the bottom of the function and, if it's `false`, add a report that explains the situation. That will ensure that something is shown, even when a configuration occurs that isn't (yet) supported by this function.
@ -369,0 +377,4 @@
anim_eval_context));
}
if (combined_result.get_count(animrig::SingleKeyingResult::SUCCESS) == 0) {

This is a bit of a weird thing to check for, given that there is a function has_errors(). I can imagine it's necessary, as there are cases in the code above where a call to insert_key_rna() is skipped, and thus it wouldn't register as error on the combined_result.

I think the weirdness comes from the use of the mechanism to track key insertion errors to track key insertion skips. I think it's better to just use combined_result.has_errors() here, as the skips already have their own calls to BKE_report.

This is a bit of a weird thing to check for, given that there is a function `has_errors()`. I can imagine it's necessary, as there are cases in the code above where a call to `insert_key_rna()` is skipped, and thus it wouldn't register as error on the `combined_result`. I think the weirdness comes from the use of the mechanism to track key insertion **errors** to track key insertion **skips**. I think it's better to just use `combined_result.has_errors()` here, as the skips already have their own calls to `BKE_report`.
Author
Member

using has_errors() is not the same as checking if there was at least one success.
The reason I am checking for 0 successes is that we don't want to spam the user with messages. E.g. there might be an FCurve that is locked and the user is aware of that, still when we use has_errors he would get an error popup every single time he wants to insert a key.

Edit:
what I did now is to explicitly check for an empty selection list and report a warning + exit early. That makes it clearer what happened.

using `has_errors()` is not the same as checking if there was at least one success. The reason I am checking for 0 successes is that we don't want to spam the user with messages. E.g. there might be an FCurve that is locked and the user is aware of that, still when we use `has_errors` he would get an error popup every single time he wants to insert a key. Edit: what I did now is to explicitly check for an empty selection list and report a warning + exit early. That makes it clearer what happened.
Christoph Lendenfeld added 2 commits 2024-03-22 15:13:49 +01:00
Christoph Lendenfeld added 1 commit 2024-03-22 15:20:07 +01:00
Christoph Lendenfeld requested review from Sybren A. Stüvel 2024-03-22 15:25:41 +01:00
Sybren A. Stüvel requested changes 2024-03-25 10:03:15 +01:00
Dismissed
Sybren A. Stüvel left a comment
Member

I think the new code is indeed better. Still, for future devs it might be a good idea to add a comment that explains why .has_errors() is not being used there.

I think the new code is indeed better. Still, for future devs it might be a good idea to add a comment that explains why `.has_errors()` is not being used there.
@ -89,0 +135,4 @@
}
if (has_reported_error) {
BKE_reportf(reports, RPT_ERROR, "%s", error.c_str());

BKE_report(reports, RPT_ERROR, error.c_str());

`BKE_report(reports, RPT_ERROR, error.c_str());`
@ -339,0 +341,4 @@
}
if (BLI_listbase_is_empty(&selection)) {
BKE_reportf(op->reports, RPT_WARNING, "Nothing selected to keyframe");

In the rest of this PR "keyframe" is only used as a noun. Maybe "Nothing selected to key" is better?

In the rest of this PR "keyframe" is only used as a noun. Maybe "Nothing selected to key" is better?
Christoph Lendenfeld added 2 commits 2024-03-26 09:26:23 +01:00
Christoph Lendenfeld requested review from Sybren A. Stüvel 2024-03-26 09:38:57 +01:00
Sybren A. Stüvel requested changes 2024-03-26 10:46:11 +01:00
Dismissed
Sybren A. Stüvel left a comment
Member

I think the text of the report could use a little bit more polish, if only to remove some repetition of the words "due to".

image

Also there's a bit of the good old singular-vs-plural going on, where a list of only one thing is a bit clunky.

How about this:

  • Remove "due to the following reasons" from the 'intro text'.
  • Instead of concatenating the strings directly and tracking bool has_reported_error, put the errors in a Vector<string>, and without the - prefix.
  • Only format the report as a list when that vector contains multiple entries. If there is only one entry, it can be shown as-is; I think even without the 'intro text' it would be descriptive enough.

I think this'll simplify the common case ,where there is a single reason for the insertion failure.

I think the text of the report could use a little bit more polish, if only to remove some repetition of the words "due to". ![image](/attachments/ec7439f0-35c1-4a82-abe4-211980d9cdd5) Also there's a bit of the good old singular-vs-plural going on, where a list of only one thing is a bit clunky. How about this: - Remove "due to the following reasons" from the 'intro text'. - Instead of concatenating the strings directly and tracking `bool has_reported_error`, put the errors in a `Vector<string>`, and without the `- ` prefix. - Only format the report as a list when that vector contains multiple entries. If there is only one entry, it can be shown as-is; I think even without the 'intro text' it would be descriptive enough. I think this'll simplify the common case ,where there is a single reason for the insertion failure.
Christoph Lendenfeld added 1 commit 2024-03-26 11:09:04 +01:00
Author
Member

Changed it so if there is only one error type, it prints solely that.
In the case of multiple error types it shows them in a list like before, with the difference that the intro text has been modified to "Inserting keyframes failed:"

Thanks for the feedback. Much better now

Changed it so if there is only one error type, it prints solely that. In the case of multiple error types it shows them in a list like before, with the difference that the intro text has been modified to `"Inserting keyframes failed:"` Thanks for the feedback. Much better now
Christoph Lendenfeld requested review from Sybren A. Stüvel 2024-03-26 11:11:10 +01:00
Christoph Lendenfeld added 2 commits 2024-03-28 16:54:06 +01:00
Christoph Lendenfeld added 1 commit 2024-03-28 17:33:05 +01:00
Sybren A. Stüvel approved these changes 2024-04-08 12:38:17 +02:00
Sybren A. Stüvel left a comment
Member

👍

:+1:
Christoph Lendenfeld merged commit 956d8379a4 into main 2024-04-09 09:39:25 +02:00
Christoph Lendenfeld deleted branch return_keying_result 2024-04-09 09:39:28 +02:00
Sign in to join this conversation.
No reviewers
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#119201
No description provided.