Godot: Editor Plugin Ideas, Improvements, Suggestions, etc. Issue.

Created on 23 Aug 2016  路  32Comments  路  Source: godotengine/godot

The Editor plugin API in Godot was mostly done with wishful thinking, and as a way to have a stable and clean API to editor functions (which may vary over time internally, or are not clean enough).

However, I'm positive that a lot of functionality for what you can do in the editor is missing from this API, thus inaccessible for plugins.

This issue is for you to write what kind of functions, objects, functionalities, etc. are missing for you, or you would like to be able to access so we add them in the next Godot version.

Feedback very welcome!

archived enhancement editor plugin

Most helpful comment

  • Draw custom stuff in the scene view from the EditorPlugin so we can draw gizmos for our own Node.

All 32 comments

Here is a list of features/fixes.

  • Fix this mouse offset bug #1885
  • Make selected nodes from EditorPlugin.get_selection().add_node(node) also be set in the properties panel or expose a function that can do it
  • store editorplugin data in with the addon which is loaded when opening the editor
  • function to create thumbnails for scenes
  • draw custom stuff from the EditorPlugin
  • enable automatic soft reload for tool scripts
  • Expose CanvasItemEditor and SpatialEditor viewports to GDScript #3992

+1 on the mouse offset bug. Currently using a messy hack to get it to work.

Also, the ability to show/hide the gizmos in 2D/3D when editing custom nodes. Functionally it doesn't matter since input can be captured, but it would be a nice visual improvement.

  • Print() should print to editor output
  • Fix this bug #6244
  • I don't know if this is a problem on my side but when I made a new node in script and added it as a child to selected node (from callback edit()), the Scene dock didn't update itself
  • Function to generate a thumbnail from script (or any supported resource). I would like to make code minimap plugin
  • Expose the names of icons in default Theme. I would like to use editor icons to make the look of my plugin consistent. I think I could call get_base_control().get_theme().get_icon but I'm not sure where to get the name and type arguments.
  • Standardized interface for sharing data between plugins
  • Draw custom stuff in the scene view from the EditorPlugin so we can draw gizmos for our own Node.
  • Communicate directly with the running game/live scene tree from a plugin being able to set a property, call a function and such
  • +1 on 'print()' should print to editor output
  • I haven't found a way to set proper child margins in WindowDialog for nice looking GUIs (C++ AcceptDialog uses set_child_rect(), not exposed). Currently I'm copying the margins from AcceptDialog::get_label()
  • Expose something like CreateDialog for import plugins that create a scene (for root node type selection as in Collada importer)

    • Instead of some sort of CreateDialog, this would be a better long-term solution if feasible: #6215

  • Draw custom stuff in the scene view from the EditorPlugin so we can draw gizmos for our own Node.

@EdwardAngeles

That's what my comment above is about. You need access to CanvasItemEditor and SpatialEditor viewports/canvases in order to draw on them.

Is there a way of sharing data between plugins? I think it should be possible but some sort of standardized interface would be appreciated.

See #5786
There should be a way for plugins to add a control to the main editing tab (2D, 3D, Script, etc) in a similar manner like AssetLib does. Useful for plugins requiring lots of real estate (say such as a plugin to manage a game project's git from within the editor). Right now there's no way to actually get an editor control into that region. This is also the region of choice for controls that provide custom editors.

  • Review edit() relevance? I feel like edit is not really needed in the API, or maybe it needs better behaviour/counterparts. I began using the edit() callback as a way to know when an object I care about is selected, however it is not called when the object is deselected, and in the end I completely based my plugin on the Selection object as I get more info and events, at the cost of a few boilerplate code.
  • Easier access to the cameras (I only know how to get the 3D one, which is an argument of forward_spatial_input_event. The 2D event has no camera argument.)
  • Add a way to know when the scene is saved, so the plugin can also save extra data that is not necessarily exported stuff
  • Automate custom control deallocation: when a plugin create custom controls, the editor can easily know who created them (owner?) and free them.
  • Automate custom type unregistration (same as above)
  • Also, solve this (I tried^^") https://github.com/godotengine/godot/issues/5977

Easier access to the cameras (I only know how to get the 3D one, which is an argument of forward_spatial_input_event. The 2D event has no camera argument.)
@Zylann

There is no Camera in 2D -- there is just canvas transform AFAIK

@bojidar-bg well, that's what I meant.

  • I'm with @Zylann about edit() relevance. I even think we don't really need make_visible callback too. EditorSelection has everything we need. And those callbacks act weirdly. If I select a node, I got two edit() callbacks (with same node) and three make_visible callbacks. At least this should be fixed.
  • EditorSelection.get_selected_nodes() doesn't return every selected node, if you want to select nodes on multiple tree levels. Like if you select two childs and then their parent, only parent is in the last selection.
    godotselection

Could someone verify my two problems please? I hope I'm not doing something wrong.

Edit: Ok, I have another:

  • I'm confused about MultiNodeEdit I get in edit(object) and handles(object) callback, if I select more than one node. How to use it? It's not documented. I guess that it's object which holds references to properties from selected nodes. Am I expected to use it? It's not even exposed in GDScript so I can't test it with extend keyword. Why can't we get an array of selected nodes like in EditorSelection.get_selected_nodes()? It leads me to my final proposal. It's just my idea how it could work:

No handles(object) callback. Let me decide if I wan't to edit selected object. I will get it from EditorSelection signal. Then, I don't need edit(object) and make_visible(visible). I can decide when to show/hide GUI from EditorSelection signal too. Forward_spatial_input_event() should work like _process callback. Let me activate this callback by function like set_forward_spatial_input_event(). Current implementation is restricting. For example, I get the array of selected nodes and user can change which node he want to edit. But I can set Forward_spatial_input_event() on and off only between handles() callbacks.

@ndee85

Fix this mouse offset bug #1885

fixed

Make selected nodes from EditorPlugin.get_selection().add_node(node) also be set in the properties panel or expose a function that can do it

added an inspect_object() function to EditorPlugin so it's up to you to do it now

store editorplugin data in with the addon which is loaded when opening the editor

I think you have get_state() / set_state() to store state in a scene-specific way, is this not enough?

function to create thumbnails for scenes

Added access to EditorResourcePreview and EditorResourcePreviewGenerator, so you can now request and generate previews for all data types, including your custom ones.

draw custom stuff from the EditorPlugin

Added proper API for forward_canvas_input_event, forward_draw_over_canvas and update_canvas to EditorPlugin, this should allow you to draw any kind of gizmo for your edited objects.

enable automatic soft reload for tool scripts

This is already supported, isn't it?

@neikeq not kind of sure if I want to expose those, since they may change and are not super clean. What kind of functionality would you like to use from them?

@eska014 Added binding to set_child_rect(), will remove this function in 3.0 and make this control behave more container-like (so anything is expanded inside automatically)

@gau-veldt Just return true when asked: has_main_screen() in EditorPlugin and it's added as a main plugin after 2D, 3D, Script, etc.

I only wanted them for drawing. Does forward_draw_over_canvas work with the SpatialEditor too?

@neikeq for Spatial editor you can use a node anywhere for drawing, or you have the Gizmo API.

@EdwardAngeles this should be already covered

@Zylann , @GlaDOSik : edit() is meaningful because most Godot editor works on the premise that editors pop up when needed. When selecting and deselecting, you don't necesarily get an edit() call.

The rest sounds like a bug :P

@GlaDOSik selection issues should be solved. MultiNodeEdit I suppose you are free from ignoring it. Not sure if it has any use for you, as you can already get the selection.

@Zylann I noted for Godot 3.0 to make plugins unregister the custom types and controls they created automatically. Will not do it now because a lot of existing stuff will break.

@reduz already tried that func has_main_screen(): return true All you get is an tab in that menu (NB: that does not go away when the plugin unloads) whose selection activates a blank Control. The plugin is not given a node representing that Control to actually be able to place a scene as a child to actually be able to use it. The editor probably needs another method, something along the lines of get_main_screen_child() that the editor calls after adding the plugin entry to the menu so the plugin may return the instance to a scene to be used in that space (which Editor would then set as child for the tab as long as plugin is loaded).

@reduz

@GlaDOSik selection issues should be solved. MultiNodeEdit I suppose you are free from ignoring it. Not sure if it has any use for you, as you can already get the selection.

Well, I want to know if user selected multiple nodes. In this case, there is a problem with callback order. If I select a node, I'm getting handles(object) callback first and after that signal selection_changed(). That means I can't decide how to handle current selection. My brightest idea was to yield in handles and wait for signal selection_changed(). It kinda worked but throwed a lot of errors.

So I think the order should be changed. I need selection_changed() first and then callback handles.

Okay so I was thinking of this idea when diving into the plugins tutorial. The documentation is well-written btw!

Suggestion:

  • Ability to add custom items to the context menu scene tree menu.

Example:
image

For example, I'm writing a script that will export my levels into json format to be used on my server. Instead of having the node highlighted, then clicking on the button, we can just right and click our custom menu item to be executed. However, this is just icing on the cake and honestly not sure what everyone thinks, but I think it'll be a cool feature down the road

I noted for Godot 3.0 to make plugins unregister the custom types and controls they created automatically. Will not do it now because a lot of existing stuff will break.

@reduz How stable is the plugin API now? This is something that still needs to be done in 3.0 AFAIK (using alpha1, not recent builds).

Hi @reduz I still see the issue with get_selected_nodes as described by @GlaDOSik in https://github.com/godotengine/godot/issues/6254#issuecomment-243595724 (v2.1.4)

I only get either child nodes or the parent. But if both parent and child is selected only the parent is returned.

Can you point me at the commit that is supposed to fix this or is this something fixed in 3.0?
Thanks!

EDIT
I assume that is the reason:
https://github.com/godotengine/godot/blob/master/editor/editor_data.cpp#L895
From the look of it the assumption is that selected root nodes imply their children are selected.
I don't know where this behaviour is needed but in my case I need all the selected nodes, including children.
Can we fix this or add an alternative interface that returns all the selected nodes?

Ok I think "get_transformable_selected_nodes" in master is what I was expected.
Do you think this can be backported to 2.1.x?

I would like to see MultiNodeEdit exposed to GDScript so that at the very least you can iterate over the collection yourself.

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!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

bojidar-bg picture bojidar-bg  路  3Comments

nunodonato picture nunodonato  路  3Comments

ndee85 picture ndee85  路  3Comments

Spooner picture Spooner  路  3Comments

blurymind picture blurymind  路  3Comments