Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow configuration warnings to refer to a property #68420

Merged
merged 2 commits into from Feb 9, 2024

Conversation

RedMser
Copy link
Contributor

@RedMser RedMser commented Nov 8, 2022

Closes godotengine/godot-proposals#550

Configuration warnings changed from PackedStringArray to an Array that accepts a mix of Strings and Dictionaries { message: String, property?: String }.
If property is set, then show a clickable warning icon on property in the inspector.
Strings in this array are converted to an equivalent Dictionary with message filled.

This PR also lays the groundwork for further configuration warning enhancements like godotengine/godot-proposals#2519

As an example, the PointLight2D node was updated to use this system.

22-11-08_20-13-15_godot.windows.editor.dev.x86_64_Snowgeese.mp4

The PR is split into two commits for easier reviewing. The second commit only fixes the signature of the get_configuration_warnings method for all classes using it.


TODO:

  • Change warning icon based on how many warnings the property has. Probably have to move the property name filtering logic out of the as_string method.
  • Would be nice to have a tooltip when hovering the icon, but since other icons don't have this yet, it can be done in a follow-up PR.
  • It seems to be necessary to introduce a compatibility method for GDExtension here.
    • No idea how to test it, so someone should verify what it's doing is correct. Especially since there's also a virtual method involved here, whose signature changed but didn't get any compat bind (I followed what was done in AnimationMixer.compat.inc)!

@Mickeon
Copy link
Contributor

Mickeon commented Nov 9, 2022

Wow... what work. My only concern is that it's not just a breaking change after 4.0, but it'd make the virtual method ever so laborious to use for simpler cases. Having to create { message: "Something is wrong etc. etc."}, that is.

I can assume that my concerns are exaggerated, as not everyone casually makes use of the method, but it makes me wonder if it could be an Array of Variant, where each one of them can either be a String or a Dictionary. This way the previous, simplistic behavior is also kept. Having it as a Dictionary is definitely the way to go, however.

@RedMser
Copy link
Contributor Author

RedMser commented Nov 9, 2022

@Mickeon I totally agree. Since there is no concrete proposal behind this, I implemented it in the most straightforward way I could think of. But for the sake of compatibility and convenience, I'd agree that treating plain strings just like before would be nice.

Would like some more opinions on this before I try implementing anything more, e.g. if this is the kind of API breakage that's also acceptable for minor versions (since like you said, this API isn't commonly used as it stands).

@MewPurPur
Copy link
Contributor

I think it's a bit weird duplicating config warnings like this. It gives off a feeling that two things are wrong, instead of just one.

If I gather correctly, this can be implemented in a not compat-breaking way, by having separate "node configuration" and "property configuration" warnings? Here's my idea:

  • Keep config warnings as is.
  • Have property warnings point to a property with a warning message.
  • Property warnings update the config warning in standardized ways, i.e. "[property_name] of this [node_name] has not been set up properly."

@Mickeon
Copy link
Contributor

Mickeon commented Nov 10, 2022

When I thought on how to implement this, I also thought of using a general String format, kind of like hint_strings, to expand the current behavior. But I do get the use of Dictionaries. I believe it allows greater control in the future. Imagine being able to click on the PhysicsBody2D's CollisionShape warning, press a button to swiftly fix the issue, and a related action Callable opens the Add Node dialog. Very convenient and user-friendly.

@RedMser
Copy link
Contributor Author

RedMser commented Jul 5, 2023

Updated so that get_configuration_warnings may be a mixed array of Strings and Dictionaries. This keeps compatibility with existing C++ and GDScript code, and keeps an easy way to write simple configuration warnings.

Also for easier review, I split the changes into two commits, since one is just a large batch of signature changes which do not need reviewing.

editor/editor_inspector.cpp Outdated Show resolved Hide resolved
editor/editor_inspector.cpp Outdated Show resolved Hide resolved
scene/main/node.cpp Outdated Show resolved Hide resolved
@KoBeWi
Copy link
Member

KoBeWi commented Jul 5, 2023

I checked the code and the implementation seems fine, but changing return type still breaks compatibility. Although Array and PackedStringArray are mostly compatible so maybe it's not a big deal.

for (int i = 0; i < boundaries.size(); i += 2) {
const int start = boundaries[i];
const int end = boundaries[i + 1];
lines.append(configuration_warning.substr(start, end - start + 1));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once #79054 is merged, the + 1 has to be removed from here.

Copy link
Member

@KoBeWi KoBeWi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation looks fine (aside from breaking compatibility; maybe there is a solution that could avoid it). There is nice flexibility with Dictionaries, which could help with #74357

Would be nice to have a tooltip when hovering the icon, but it doesn't seem like that's easily possible with these "inline" icons? Would like to hear suggestions on how to tackle this.

This can be implemented using get_tooltip() virtual method and new_configuration_warning_hover. But other icons don't have tooltips; it could be implemented for all of them in another PR.

@Mickeon
Copy link
Contributor

Mickeon commented Jan 24, 2024

Yyyeaah, this one cannot be done now without breaking compatibility, unless it is possible for it not to.

@RedMser
Copy link
Contributor Author

RedMser commented Feb 8, 2024

Hi @Mickeon , your PR #87535 removed Node::get_configuration_warnings_as_string which I intended to use here.

Clicking on the ⚠️ button that appears next to a property, a dialog similar to the one from the scene tree would show up. It would filter to only show relevant warnings, so the function would get an optional property parameter. (As discussed above, tooltips aren't currently implemented for inspector buttons, so the dialog would be the primary way to get this info for now...)

Without the function, this would involve duplicating the logic involving the bullet points, indenting new lines etc.

Do you think it would be fine to re-introduce it here, now that there'd be multiple places that need it for different purposes? Or was there a strong reason against having that function around in the first place?

@Mickeon
Copy link
Contributor

Mickeon commented Feb 8, 2024

Do you think it would be fine to re-introduce it here, now that there'd be multiple places that need it for different purposes? Or was there a strong reason against having that function around in the first place?

The reason it was removed was because it was only used two times: The tooltip, and the popup. However, the way these two are displayed is entirely different, to the point where relying on that function's result was basically useless, as the strings had to be reformatted anyhow. It also was not encompassed with TOOLS_ENABLED, which included it in release builds for no reason (if the compiler is stupid).

With that said, I am not sure if it should be brought back. At the same time, this PR may override what was made in #87535, so you may as well... go all in?

The original popup itself has always kind of sucked, this may be an opportunity to refactor it outright.

Copy link
Member

@AThousandShips AThousandShips left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code and documentation looks good

This is used by the inspector so it can show a warning icon on
a specific property.
@akien-mga akien-mga merged commit 86ffe92 into godotengine:master Feb 9, 2024
16 checks passed
@akien-mga
Copy link
Member

Thanks!

@KoBeWi KoBeWi mentioned this pull request Feb 10, 2024
@Zylann
Copy link
Contributor

Zylann commented Feb 10, 2024

What should GDScript plugins do if they support engine versions prior this change?

func _get_configuration_warnings() -> PackedStringArray:

Updated so that get_configuration_warnings may be a mixed array of Strings and Dictionaries. This keeps compatibility with existing C++ and GDScript code

GDScript doesn't have a preprocessor to make this conditionally implemented differently. If I write -> Array, it will break in versions prior this change.
That means I have to remove typing.

@KoBeWi
Copy link
Member

KoBeWi commented Feb 10, 2024

That means I have to remove typing completely.

Yes, that's the solution if you want to support older versions.

Comment on lines -639 to +644
virtual PackedStringArray get_configuration_warnings() const;
virtual Array get_configuration_warnings() const;
Dictionary configuration_warning_to_dict(const Variant &p_warning) const;
Vector<Dictionary> get_configuration_warnings_as_dicts() const;
Vector<Dictionary> get_configuration_warnings_of_property(const String &p_property = String()) const;
PackedStringArray get_configuration_warnings_as_strings(bool p_wrap_lines, const String &p_property = String()) const;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In #81892 I proposed removing the String conversion method from Node, as it's only used by the editor. This PR is going in the opposite direction, adding more formatting methods to Node.

IMO, only virtual Array get_configuration_warnings() const; should exist in Node. The rest are editor-specific.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is very fair. Since they are not bound methods (and shouldn't be), it's not a problem to move them elsewhere as a refactor further down the line.

I just don't know enough about organization in C++ to really know a good place for them, or if you can just create a editor_configuration_warnings.cpp file for this and it'll magically work?

Copy link
Contributor

@Mickeon Mickeon Feb 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that it was also removed in #87535 for similar reasons.

(Also note that this change has been more compatibility-breaking than previously assumed. Heck).

Comment on lines -323 to +324
GDVIRTUAL0RC(Vector<String>, _get_configuration_warnings)
GDVIRTUAL0RC(Array, _get_configuration_warnings)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This breaks binary compatibility for GDExtension. Any GDExtension that implements _get_configuration_warnings() from before this change will probably segfault. Does anyone know if there's an issue discussing this yet? If not, I can make one

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just created issue #88379

akien-mga added a commit that referenced this pull request Feb 17, 2024
…on_warnings-compat-breakage

Revert #68420 to undo `get_configuration_warnings` compat breakage
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

An export variable hint which shows a warning icon if the value has not been set in the inspector