godot
godot copied to clipboard
Add `@tool_button` annotation for easily creating inspector buttons.
Supersedes: https://github.com/godotengine/godot/pull/59289 Closes: https://github.com/godotengine/godot-proposals/issues/2149

- [x] I see you replaced UndoRedo with EditorUndoRedoManager in response to my comment. Unfortunately it won't work, because all actions should go through EditorUndoRedoManager.
- [ ] Need to test api changes
TOOL_BUTTON as well as GROUP should be a "pseudo member" and must not shadow real members in members_indices, see #78254. In property list the names should be different too, I think (unlike GROUP).
To change the order of a tool button in the inspector, are you forced to move the function up? This does not follow the GDScript style guide, which recommends that variables be placed above functions.
To change the order of a tool button in the inspector, are you forced to move the function up? This does not follow the GDScript style guide, which recommends that variables be placed above functions.
The last time we discussed the syntax it was suggested that you can add the annotation wherever you want if you pass a callable "reference" to it, see https://github.com/godotengine/godot/pull/59289#issuecomment-1155140377.
Can you explain how this affects this pr? Like how to change?
Can someone help me test this? Also, does anyone know how to call this feature from c++?
Any news on this PR? This would be fantastic when creating plugins or editor tools.
I too would love an update on this. Just downloaded 4.3-dev2 like a muppet thinking it would be in there!
Is this still on track to make 4.3?
It's been abandoned by the author and needs to be salvaged, so it's waiting for someone to pick it up and continue the work
I might be insterested in picking it up.
Can you please summarize for me why the (arguably, overcomplicated) design with do/undo was chosen?
For my use cases, these actions I want @tool_button to perform are approximately never easily undo-able.
For example, I'd have a build_mesh action which would start by dropping the old mesh, and just building a new one instead, etc.
Wouldn't it be much simpler and more user-friendly to give up on undo?
@export var mesh_parameter: int = 42
@tool_button("Build mesh.")
func build_mesh():
# Use mesh_parameter here, no function arguments allowed
This is exactly what people use the "boolean hack" for these days, only nicer and without the ugly workaround code.
Undo/redo functionality would be used by a plugin or tool developer. Click an inspector button to process the mesh. Oops, undo. The tool developer has the option to connect their do and undo functions so the action gets logged in Godot's history and users can use them. It should also give the developer the option of providing a null undo callback so the functionality can be ignored by devs making hacks for their own use, IMO. But then these folks don't really need a tool button, as the boolean hack will suffice.
This feature could be added without undo/redo concerns by using a confirm dialogue.
Undo/redo functionality would be used by a plugin or tool developer.
I'm not sure to understand why plugin or tool developper can't use the regular UndoRedo class to implements this if they need it ? (In fact, I use the EditorUndoRedoManager but never the regular UndoRedo, so maybe I miss something)
You can. You're going to provide do and undo functions either way. This uses undo/redo in the background, so it's just more concise, syntactic sugar.
You can. You're going to provide do and undo functions either way. This uses undo/redo in the background, so it's just more concise, syntactic sugar.
Then, IMHO it's not a good idea to make "regular" user to have to provide a null undo callback as they probably would be the main users of this feature... On my addons, I'm personally not really bothered to have to use a specific UndoRedo API to handle this pretty advanced feature (and for now, I mainly used an EditorPlugin, EditorNode3DPlugin and EditorNode3DGizmoPlugin to perform undoable actions).