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 EditorNode to plugins #6520

Closed
Tracked by #6276
vnen opened this issue Sep 17, 2016 · 5 comments
Closed
Tracked by #6276

Expose EditorNode to plugins #6520

vnen opened this issue Sep 17, 2016 · 5 comments

Comments

@vnen
Copy link
Member

vnen commented Sep 17, 2016

The core editor plugins have major advantage over GDScript plugins: the access to the EditorNode singleton. Many of the EditorPlugin functions are just wrappers to EditorNode 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 inside EditorPlugin like I did in #6516.

@reduz
Copy link
Member

reduz commented Jun 28, 2017

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

@vnen
Copy link
Member Author

vnen commented Jun 28, 2017

@reduz looking at it now I can understand, but WDYT of my last phrase:

The alternative, of course, is making more EditorNode wrappers inside EditorPlugin.

There are some useful things to use like reload_scene() for importers.

@kubecz3k
Copy link
Member

kubecz3k commented Jul 18, 2017

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.

@kubecz3k kubecz3k added this to the 3.1 milestone Jul 18, 2017
@akien-mga
Copy link
Member

Moving to the next milestone as 3.1 is now feature frozen.

@akien-mga akien-mga modified the milestones: 3.1, 3.2 Sep 15, 2018
@akien-mga akien-mga removed this from the 3.2 milestone Nov 11, 2019
@akien-mga
Copy link
Member

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!

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

4 participants