Godot: Add a "Plugins" or "Tools" menu option

[vinod8990]

Since godot features can be extended by plugins, later the editor will have no space for plugin buttons. So please add a Tools menu option in the editor itself. So that all plugin developers can add their menu items(may be categorized) into it.

[reduz]

I think EditorPlugin has a function to add menus to different parts of the
UI, is this what you mean or something else?

On Tue, Feb 24, 2015 at 2:00 AM, Vinodkumar KN [email protected]
wrote:

Since godot features can be extended by plugins, later the editor will
have no space for plugin buttons. So please add a Tools menu option in the
editor itself. So that all plugin developers can add their menu items(may
be categorized) into it.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1429.

[vinod8990]

Editor Plugin has some predefined positions. But after adding so many plugins, godot will run out of space of Plugin buttons.
I think it is better to add a global menu like 'Tools' into which developers can add all plugins.

[akien-mga]

There is now a "Tools" global menu I think, so it could probably be used to put plugins in it. Someone would have to check if that can be done easily already, or if some changes are needed to make plugins appear in this menu.

[vnen]

AFAICT, to add a custom control in the editor, one have to rely on EditorPlugin.add_custom_control(), which has a somewhat limited range of places to put new controls.

[akien-mga]

So I guess this issue should be about adding more possibilities to the places available for EditorPlugin.add_custom_control()?

[neikeq]

It should be easy to do. I propose Tools->Plugins (where Tools already exists, and Plugins would be a submenu). Another option is directly in Tools. I can add it if you give me greenlight.

[akien-mga]

I think it could be added directly in the Tools menu, which is anyway not too crowded so far. Maybe at the end of the list with a separator between built-in tools and plugin tools?

[vinod8990]

Can we categorize it with a sub menu as the plugin developer's needs.
So if we want a sub menu for let's say terrain.
So add menu items for
"terrain/add terrain"
"terrain/paint texture"

Etc

[akien-mga]

Anyone up to implementing this? @MarianoGnu, @neikeq, @TheHX? :)

[ghost]

I'm up for implementing this, i was thinking on creating a class for this, so it can be more flexible. I created a simple header to demonstrate the API for the class: tool_menu.h.

[MarianoGnu]

I don't belive a class is worth, this should be handled the same way other containers do, adding functions to EditorNode and exposing them to EditorPlugin class.
The menu i propose
Plugins
-Create plugin
-import plugin
-manage plugins (quick enable/disable)
--plugin 1
--plugin 2
---------- (separator)
-custom buttons

The functions to expose:
add_plugin_menu_button(name,handler,function)
remove_plugin_menu_button(name)
exist_plugin_menu_button(name)

name can be like "tileset plugin/create”

[bojidar-bg]

@MarianoGnu maybe exist_plugin_menu_button -> has_plugin_menu_button?

[ghost]

I don't like the idea of adding the custom buttons into the "Plugins" menu, i prefer to add they to the "Tools" menu, so developers can add more options to the menu.
And i still think the creating a new class worth in this case, we can reduce the code added directly into the EditorNode source, and, in the future, and we can reuse the code for others menus which plugin developers want to expand.
I agree with the functions to expose, but it's missing a function to create a submenu.

[MarianoGnu]

I know EditorNode is a little bloated, but a preffer to keep consistense on the way things are done, otherwise you should move all other container to specific classes, and they are not exposed to GdScript anyway

[MarianoGnu]

@MarianoGnu maybe exist_plugin_menu_button -> has_plugin_menu_button

I like that

[ghost]

I want to create the new class based on #5691. But is ok to me add the code into the editor_node.*.

[ghost]

Here's my proposal for the API, based on @MarianoGnu initial proposal.

# I think it's better to add a optional ID parameter to the button
# If the ID is the default value, the ID of the item is the index of the items in the category
# Ex:
#     "my_plugin/item1"; ID = 0
#     "another_plugin/item1"; ID = 0 # But probably the plugin buttons won't be mixed, this is just a example.
#     "my_plugin/item2"; ID = 1
#     "my_plugin/item3"; ID = 2
#     "another_plugin/item2"; ID = 1
# The name parameter is in format "my_plugin_name/my_button_item" or "MyPluginName/MyButtonItem" and in menu it'll display "My Button Name"
# In this case the callback function is in format void callback(String name, int ID)
void add_plugin_menu_item(String name, Object handler, String callback, int ID = -1);

# The name parameter is in format is "my_plugin_name/submenu_name" (submenu_name == submenu.get_name())
void add_plugin_submenu_item(String name, PopupMenu submenu);

void remove_plugin_menu_item(String name);
bool has_plugin_menu_item(String name);

IMO it's better change the functions names from *_menu_button to *_menu_item to be closer to the naming of the PopupMenu API.

[MarianoGnu]

About id, just add an Array args and default it to [], then you can use the same function for everithing :)

[akien-mga]

Fixed by b24b52d.