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

Make GroupsEditor and SceneEditorTree react to changes from an EditorProperty #2925

Open
jabsatz opened this issue Jun 27, 2021 · 0 comments

Comments

@jabsatz
Copy link

jabsatz commented Jun 27, 2021

Describe the project you are working on

A small editor plugin (https://github.com/jabsatz/Scene-Manager)

Describe the problem or limitation you are having in your project

I have defined an EditorProperty that adds the selected node in the inspector to a group. While this works fine, the UI does not update correctly, since it doesn't react to any emitted change in groups.
The only way for me to update the UI is to manually look for the SceneTreeEditor and GroupsEditor from the EditorInterface and run update_tree() on them. This is extremely easy to break as the user could have other addons or a different godot setup so I can't find these nodes manually.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

There are two possible solutions I see:

  1. Make the GroupsEditor and SceneEditorTree react to an emitted change in groups defined in EditorProperty, so that if I do for example emit_changed('groups', []), all the groups will disappear from these two nodes.
  2. Add two new methods to EditorInterface (get_groups_editor() and get_scene_editor_tree()) to recieve direct references to these nodes. This way I'm able to update them without worrying about the user having a different godot setup

In my mind though, the best solution is the first one, since it seems like a bug to not have that option.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The change for the first solution doesn't seem too big. I've looked around the godot repo and it seems like the change required would be in groups_editor.cpp. I will write the steps since I'm not too comfortable with C++

  1. Add a new method to GroupsEditor class called update_groups
  2. This method should call this->update_tree() and EditorNode::get_singleton()->get_scene_tree_dock()->get_tree_editor()->update_tree()
  3. In the constructor for GroupsEditor, get a reference to EditorInspector from EditorNode->get_inspector() and connect the property_changed signal to GroupsEditor.
  4. In the handler for that connection, if the property_changed is groups, run the update_groups function.

As for the second solution, it seems even smaller. The changes would be in editor_plugin.cpp for the EditorInterface GDScript class:

  1. Add a new get_groups_editor method that returns the GroupsEditor (could not easily find a way to get it, maybe a new EditorNode method needs to be defined as well.
  2. Add a new get_scene_editor_tree method that returns EditorNode::get_singleton()->get_scene_tree_dock()->get_tree_editor()

If this enhancement will not be used often, can it be worked around with a few lines of script?

This is the way I found to circumvent it in my code:

var editor_interface = EditorPlugin.new().get_editor_interface()
var group_tree = editor_interface.get_inspector().get_parent().get_parent().get_child(1).get_child(2)
var scene_tree_editor = editor_interface.get_base_control().get_child(1).get_child(1).get_child(1).get_child(0).get_child(0).get_child(0).get_child(3)

# then in my handler
group_tree.update_tree()
scene_tree_editor.update_tree()

However as explained in the first point, this requires users to have the exact same editor distribution I have, so I wouldn't consider it a possible solution.

Is there a reason why this should be core and not an add-on in the asset library?

As far as I can tell, this cannot be done from an add-on. I know GDNative exists, and I think maybe it could be solved with that, but the documentation is sparse and this seems like an oversight on the main engine's side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants