Add support for custom items to editor right-click context menus

[citizenll]

Add right-click menu plugin functionality to implement this proposal

Currently, I am only working on 3.x, but in order to incorporate this feature, this is a feature version of 4.x. The difference compared to 3.x is that additional submenu options have been added (currently only expanding the create new option for filesystem).

submenu options example

extends EditorContextMenuPlugin
const PLUG = preload("res://addons/context-plugin/plug.svg")

func _can_handle(paths: PackedStringArray) -> bool:
	return true

func _init() -> void:
	add_context_menu_item(PLUG, "Svg...", _handle_create_svg, SUBMENU_SLOT_FILESYSTEM_CREATE)

func _handle_create_svg(args):
	print(args)

Please refer to the 3.x submission for a more detailed explanation here

• Bugsquad edit, closes: Support adding custom items to editor right-click context menus godot-proposals#2401 Closes Add a way to add "Create new..." entries godot-proposals#8254

[KoBeWi]

So I tested this and it works, but the API is super weird.
add_context_menu_item() does not add an item, it defines an item that will appear when plugin is activated. This means that each plugin can add only one menu item. The function's first argument is an icon, which is completely optional for menus. Also if you don't call this method, the editor will crash.
There is SUBMENU_SLOT_NONE which does nothing (?) and SUBMENU_SLOT_FILESYSTEM_CREATE, which is a part of different enum and can't be used.

I think instead of _can_handle(), there could be _popup_menu(arguments: Array) virtual function. Though maybe paths is fine, not sure where else we will want to add options.
Inside that function the user is supposed to call add_context_menu_item(), as many times as they want. I'd change the signature to add_context_menu_item(text: String, callback: Callable, icon: Texture2D = null, shortcut: Shortcut = null). The plugin would have a vector of structs representing added menu items. The editor would then use this vector to add menu items to the PopupMenu.

Instead of keeping an array of plugins per slot, I think it can be a single LocalVector. When opening menu, go through the vector and check the plugin slot. If the slot matches, call _popup_menu() and then add options to menu.

To make your life easier, this can be handled with internal methods:
add_options_from_plugins(PopupMenu *p_menu, ContextMenuSlot p_slot, const PackedStringArray &p_paths) (this can be a method in EditorData; you need to keep the registered plugins somewhere)
EditorContextMenuPlugin::add_options(const PackedStringArray &p_paths) - it would clear the option structs vector, call the virtual _popup_menu() and then add items based on added options.

Feel free to ask if something is not clear. You can also join the developer chat.

[citizenll]

Based on the recommendations, the final API has been adjusted; _can_handle has been changed to _popup_menu. The method add_context_menu_item will store data in a local HashMap, meaning that menu items with the same name will be unique. Additionally, to enhance understanding, submenu slots are now on the same level as other slots. Below is the example code.

extends EditorContextMenuPlugin
const PLUG = preload("res://addons/csv-update/plug.svg")

func _popup_menu(paths: PackedStringArray) -> bool:
	## The return result will determine whether to display the added options.
	add_context_menu_item("File Custom options", handle, PLUG)
	return true

func handle(paths):
	print("file context item handle:", paths)

[KoBeWi]

This could be moved to EditorContextMenuPlugin instead.
EditorPlugin has similar enums, but they don't have a dedicated class.

[KoBeWi]

Looking at all the new methods in EditorData, I think they can be moved to some new class called EditorContextMenuManager 🤔 Like EditorInspector manages inspector plugins or 3D editor manages gizmo plugins etc.
Though they are completely internal, so this can be done in a future refactor.

[citizenll]

The scene tree and script editor plugin both receive input events simultaneously... How should I handle this...? When I use the same shortcut, they both respond at the same time, which means that the shortcuts in these two areas cannot be the same.

The code supporting shortcuts has been updated. Currently, it should restrict the scene tree and code editor from using the same shortcuts. If there are no other issues, I will supplement the documentation, and we can close this PR.

[KoBeWi]

Needs description.

[KoBeWi]

I think functionality-wise it's ok now and the implementation is good enough. It can be merged once you address some last comments.

[akien-mga]

Amended the commit message to match our preferred style for clarity.

[citizenll]

Oh, what have I done? I thought I was just supposed to modify the commit message. Did my resubmission break anything?

[AThousandShips]

You fixed the message but it had already been fixed, and your branch was behind this one so you pulled it back to an earlier version

[citizenll]

Will my new force push affect this modification? Do I need to correct this error, or can I leave it as is? I'm not sure how to handle the pull request in this situation.

[AThousandShips]

You can leave it, I updated the PR message to match, but it's good in the future to pay attention to what happens in your PR to avoid undoing or redoing things

[akien-mga]

My bad, I should have been more explicit that I did the action myself, and wasn't asking for you to do it :)

[akien-mga]

Thanks! And congrats for your first merged Godot contribution 🎉