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

Editor not removing name from menu when plugin defining has_main_screen() (return true) and get_name() is deactivated #5754

Closed
Tracked by #6276
gau-veldt opened this issue Jul 17, 2016 · 1 comment · Fixed by #6516

Comments

@gau-veldt
Copy link
Contributor

gau-veldt commented Jul 17, 2016

Operating system or device - Godot version:
Godot v2.1.beta.official

Issue description (what happened, and what was expected):
Okay an EditorPlugin putting a scene as a child of its EditorPlugin node has one very big issue - it goes over top menus!!! That will not work for anything other than temporary popup dialogs, certainly not for any long-lived editor control. I still do not have complete information on how to properly make an EditorPlugin that uses the edit area used by 2D, 3D, Script, AssetLib. It's clear that defining has_main_screen() and get_name() are not enough here. For one thing there needs be a method the plugin can call to determine the appropriate parent to place the plugin's edit controls (as a scene). Overriding .edit() also isn't the solution here because edit controls like AssetLib don't edit a defined object type yet can still use this area.

Furthermore the editor automatically adds your plugin's name (the string returned by the plugin's overridden .get_name() method) to the edit mode (2D, 3D, Script, AssetLib) menu when it activates but does not remove it when the plugin is deactivated. This is most likely a bug since the plugin itself has no way to remove its name from that menu since the script itself never added it to begin with.

Steps to reproduce:
plugin.gd:

func get_name():
  return "MyPlugin"

func has_main_screen():
  return true

func _enter_tree():
  # plugin does not itself the name into the menu as
  # editor does this automatically when plugin activated
  pass

func _exit_tree():
  # the editor automatically added plugin's name
  # thus there is nothing to uninitialize to remove the name
  pass

Link to minimal example project (optional but very welcome):
(The above script should be referred by an appropriate plugin.cfg that references it)
When activated it will appear in the menu alongside 2D, 3D, Script, AssetLib (etc.) but when deactivated the plugin's menu name (string returned by overridden get_name() method) that was automatically added on activation is not correspondingly removed.

@gau-veldt gau-veldt changed the title EditorPlugin: main_screen mode does not remove plugin's name from menu on deactivation Editor not removing name from menu when plugin defining has_main_screen() (return true) and get_name() is deactivated Jul 17, 2016
@gau-veldt
Copy link
Contributor Author

gau-veldt commented Jul 18, 2016

I'm guessing about the current implementation but so far I have established that a plugin's has_main_screen() method is only called on activation so modifying a plugin's uninitialize behavior in _exit_tree() to make that method return false when deactivated does not remedy the problem (I tried this in my experimentation as a workaround to the problem).

This leads me to suspect the editor has not remembered it has placed elements into the menu. A solution therefore would be for the editor to store the object id and menu slot position chosen for the menu text of any plugin that returns true on its has_main_screen() method (and whose overridden get_name() returns a non-empty string). When the plugin is eventually deactivated the editor looks through the list and if it gets an entry for the object id of the plugin about to be deactivated it has the position index for which menu item to erase.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants