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

Control::gui_input is not exposed #1426

Open
GreenCrowDev opened this issue Mar 29, 2024 · 3 comments
Open

Control::gui_input is not exposed #1426

GreenCrowDev opened this issue Mar 29, 2024 · 3 comments
Labels
discussion enhancement This is an enhancement on the current functionality topic:gdextension This relates to the new Godot 4 extension implementation

Comments

@GreenCrowDev
Copy link

Godot version

4.2.1

godot-cpp version

4.2

System information

Windows 11

Issue description

Control::gui_input is not exposed and Control::_gui_input is not its GDExtension counterpart, not allowing sending events to other Control nodes with specific behaviours.

The use case is trying to reproduce the behaviour of Godot visual shader editor add node dialogue, where you can filter the options with a LineEdit on focus, while also being able to go up and down with the keyboard among the filtered member options in the Tree.

immagine

This is the code you want to be able to call to sent events to Tree *member (from https://github.com/godotengine/godot/blob/master/editor/plugins/visual_shader_editor_plugin.cpp)...

void VisualShaderEditor::_sbox_input(const Ref<InputEvent> &p_ie) {
	Ref<InputEventKey> ie = p_ie;
	if (ie.is_valid() && (ie->get_keycode() == Key::UP || ie->get_keycode() == Key::DOWN || ie->get_keycode() == Key::ENTER || ie->get_keycode() == Key::KP_ENTER)) {
		members->gui_input(ie);
		node_filter->accept_event();
	}
}

...but changing members->gui_input(ie); to members->_gui_input(ie); has not the same results, as _gui_input() in GDExtension has only overriding purposes as of now.

I'll quote a comment by @Zylann from https://github.com/Zylann/godot_voxel/blob/master/editor/graph/voxel_graph_node_dialog.cpp as it seems he found the same issue:

// TODO GDX: Control::gui_input() is not exposed to GDExtension, can't forward events.
// This is what VisualShaderEditor::_sbox_input does.
// _gui_input is exposed, but that's only for user implementation, not for calling directly...
// Also gui_input is a name already taken in GDScript, so if it gets exposed some day, it will need a
// different name.
//
// _tree->gui_input(key_event);

Will it be exposed correctly in the future?

Steps to reproduce

As explained in the description, try to use _gui_input() on any Control child class.

Minimal reproduction project

No minimal reproduction project needed.

@AThousandShips
Copy link
Member

The gui_input method isn't exposed to scripting, and therefore also not exposed to extensions, sending _gui_input directly in GDScript is not recommended, the virtual callbacks shouldn't be handled that way, so this would first have to be exposed as some input passing method in scripting, but I'm not sure simulating input events is something we should allow

This isn't a bug but a missing feature, so this should be a proposal as it's not specific to GDExtension either

@AThousandShips AThousandShips added enhancement This is an enhancement on the current functionality discussion topic:gdextension This relates to the new Godot 4 extension implementation labels Mar 29, 2024
@Zylann
Copy link
Collaborator

Zylann commented Mar 29, 2024

I'm not sure simulating input events is something we should allow

If that's the case then core tools shouldn't be allowed to do that either, it's a hack. Instead there should be a regular way of doing it that anyone can use (in particular plugins and extensions).

One thing to note, simulating input can also be useful for writing automatic tests (unless that already exists in some other form?)

@AThousandShips
Copy link
Member

AThousandShips commented Mar 29, 2024

The core tools are different IMO, there's plenty of things that are done on the C++ side, and modules, so I'd say it's not a hack as such when the engine itself does things like this, in controlled ways, though this specific case could probably be handled better by using other features of Tree

But I'm not against adding ways to pass input control like that, but it should be a proposal and be discussed in one

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion enhancement This is an enhancement on the current functionality topic:gdextension This relates to the new Godot 4 extension implementation
Projects
None yet
Development

No branches or pull requests

3 participants