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 EditorNode to plugins #6520
Comments
EditorNode changes a lot and the overall interfaces are pretty dirty. The interfaces are abstracted in EditorPlugin just to avoid the mess of EditorNode and provide an API that will be unlikely to change |
@reduz looking at it now I can understand, but WDYT of my last phrase:
There are some useful things to use like |
I added 3.1 milestone since I remember reduz was talking about EditorNode refactoring in 3.1. So I guess we will consider then what to do with this issue. |
Moving to the next milestone as 3.1 is now feature frozen. |
Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine. The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker. If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance! |
The core editor plugins have major advantage over GDScript plugins: the access to the
EditorNode
singleton. Many of theEditorPlugin
functions are just wrappers toEditorNode
methods.The core C++ plugins are quite good examples on how to extend the editor but they require unavailable API. For instance, the Theme editor is quite good for being context sensitive. You can't do that in a custom plugin since it's impossible to show and hide the bottom panel without access to
EditorNode
.Is there a reason why
EditorNode
is not fully exposed?The alternative, of course, is making more
EditorNode
wrappers insideEditorPlugin
like I did in #6516.The text was updated successfully, but these errors were encountered: