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

Expose PropertySelector to scripting #81488

Closed

Conversation

nlupugla
Copy link
Contributor

@nlupugla nlupugla commented Sep 9, 2023

Exposed PropertySelector to scripting so aid addon/plugin development

Closes godotengine/godot-proposals#7635.

Todos:

  • Run doctools to generate documentation
  • Fix error Parse Error: Native class "PropertySelector" cannot be constructed as it is abstract
  • Test in minimal project

@nlupugla nlupugla force-pushed the expose-property-selector branch from 5e6e542 to 06913d5 Compare September 9, 2023 16:21
@AThousandShips
Copy link
Member

You need to run --doctool to generate documentation for the newly exposed class, and fill in the documentation

@AThousandShips AThousandShips changed the title Exposed PropertySelector to scripting Expose PropertySelector to scripting Sep 9, 2023
@@ -575,7 +575,29 @@ void PropertySelector::set_type_filter(const Vector<Variant::Type> &p_type_filte
type_filter = p_type_filter;
}

//Variant::Type isn't exposed, so need a version that takes int
Copy link
Member

Choose a reason for hiding this comment

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

Variant::Type is exposed.

Copy link
Member

@AThousandShips AThousandShips Sep 10, 2023

Choose a reason for hiding this comment

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

Indeed: here, and used here

The reason it is not indicated as the return type of methods like typeof is that the methods in @GlobalScope are not providing full metadata

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the review!

Ah, I see, that makes sense!

Nevertheless, I am getting an error from ClassDB::bind_method when I try to bind set_type_filter instead of set_type_filter_exposable

In template: implicit instantiation of undefined template 'GetTypeInfo<const Vector<Variant::Type> &>'

Is it maybe because Variant::Type isn't itself a Variant so it can't be implicitly converted from Vector<Variant::Type> to TypedArray<Variant::Type>?

Copy link
Member

@AThousandShips AThousandShips Sep 10, 2023

Choose a reason for hiding this comment

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

You need to use TypedArray, Vector will only work if it's a packed case I think, as there's no direct conversion between Vector and Array, and no automatic conversion is done in the binds at all AFAIK, it just uses the built-in calling methods

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I tried that first actually, and it also gave an error. I tried it again just now, and this is the error I get:

In template: no member named 'get_class_static' in 'Variant::Type'

Thanks for helping me out with this :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay. Any ideas for a better comment to explain the choice? Maybe Need a version that takes int because TypedArray<Variant::Type> is not valid.

Copy link
Member

Choose a reason for hiding this comment

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

TypedArray<int> because TypedArray<Variant::Type> is not supported.

Copy link
Member

Choose a reason for hiding this comment

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

I didn't realize Variant::Type couldn't be used with TypedArray<T>. Would it be possible to make it work? If so, it'd be nice to do it before shipping this API; otherwise, we won't be able to change it later to avoid breaking compat.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My guess is that it's because Variant::Type isn't a variant, and TypedArray can only hold Variants. I could be totally wrong here though. Who would be the best person to ask about it?

Copy link
Member

Choose a reason for hiding this comment

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

Possible that it's caused by a lack of enum conversion, will look into it

@@ -174,6 +175,7 @@ void register_editor_types() {
GDREGISTER_CLASS(EditorResourcePicker);
GDREGISTER_CLASS(EditorScriptPicker);
GDREGISTER_ABSTRACT_CLASS(EditorUndoRedoManager);
GDREGISTER_CLASS(PropertySelector);
Copy link
Member

Choose a reason for hiding this comment

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

It seems we tend to prefix the exposed classes with Editor, we should consider renaming this class before exposing it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good idea! Would this involve doing a refactor throughout the whole codebase? I can do that, it will just add a lot more files changed to the PR.

Copy link
Member

Choose a reason for hiding this comment

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

It may be better to wait for the Editor team to offer their opinion since this is not my area. But I think if we decide to rename the class it should likely be done in this PR.

@@ -78,6 +78,7 @@ class PropertySelector : public ConfirmationDialog {
void select_property_from_instance(Object *p_instance, const String &p_current = "");

void set_type_filter(const Vector<Variant::Type> &p_type_filter);
void set_type_filter_exposable(const Vector<int> &p_type_filter);
Copy link
Member

Choose a reason for hiding this comment

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

I think when we need to provide another method just for the bindings we usually use the _bind suffix, but it's not too important since this name won't be part of the public API. I think we also make these methods private and therefore prefixed with an underscore (_).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

as in public set_type_filter -> private _set_type_filter and public set_type_filter_exposable -> public set_type_filter_bind ?

Copy link
Member

Choose a reason for hiding this comment

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

I'd say private _set_type_filter_bind

Bind methods shouldn't be public (they are private almost always, with some exceptions that I think are mistakes)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, I see. So public set_type_filter and private _set_type_filter_bind then.

Copy link
Member

Choose a reason for hiding this comment

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

Yep, it's not uniform but private methods should be prefixed by _, they should be private to keep them internal, and communicating that it is a bind method is just a good practice to avoid any confusion.

@nlupugla
Copy link
Contributor Author

Superseded by #81655.

@nlupugla nlupugla closed this Sep 14, 2023
@nlupugla nlupugla deleted the expose-property-selector branch September 14, 2023 16:51
@YuriSizov YuriSizov removed this from the 4.x milestone Sep 14, 2023
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.

Expose PropertySelector to scripting
5 participants