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

Inconsistent partial mouse event handling for unfocusable windows #84700

Open
lostminds opened this issue Nov 10, 2023 · 1 comment
Open

Inconsistent partial mouse event handling for unfocusable windows #84700

lostminds opened this issue Nov 10, 2023 · 1 comment

Comments

@lostminds
Copy link

Godot version

4.2beta5

System information

macOS 14.1

Issue description

While trying to build some custom interface controls that feature dropdown components (like a custom menu button popup with further controls) I've run into some issues and inconsistencies with the unfocusable property on Windows.

Allowing windows to popup without activating (as in not deactivating the current/parent window) is very useful for controls like dropdown menus, tooltips, hover-controls and such. However, the unfocusable property of Godot Windows has a couple of issues when used for this type of functionality:

When used on non-embedded windows it works as intended in that it does not deactivate the current window. However, the popup window controls do not get mouse move (enter/exit) or key events, but they do get mouse click events. As you can see below, the cursor change is also triggered, so the mouse areas are still tracked, but the controls don't get the enter/exit signals based on this.

unembedded_windows.mov

Since the menu button menus also use this type of non-activating non-embedded window and they are able to track mouse enter/exit events on their items it must be technically possible in the engine. Perhaps these PopupMenu nodes have some special implementation to get around the regular unfocusable limitations?

When used on embedded windows it instead works the other way around. We now get mouse enter/exit events, but no click events for the controls in the window:

embedded_windows.mov

Reading the docs for unfocusable it states briefly that "If true, the Window can't be focused nor interacted with.". If this is intended to include window content it is apparently not true in either case, but could explain why some events are blocked.

However, in my mind that is not desirable either. The main use-case for having this type of window is I think for control popup components as explained above. And in these cases it's likely that you also want to get at least all mouse events. In other words that "unfocusable" should be clarified to mean that the window can't become the active window, but that the controls can still be interacted with in it. If you want to disable input in a window there is already a separate dedicated setting for this with the Window Viewport.gui_disable_input property.

Steps to reproduce

  • Set the project setting not to embed sub-windows

  • Make a scene with a Window with unfocusable turned on

  • Put a button control in the window

  • Run and observe that you can click and press the button, but it does not respond to hover.

  • Change the project setting to embed sub windows

  • Run and observe that you can now get hover response on the button, but not click.

Minimal reproduction project

NonActivatingWindowsMouse.zip

@lostminds
Copy link
Author

Tested again in 4.2b6 and the fixes to mouse enter/exits in #84547 do not seem to have affected this issue.

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

No branches or pull requests

2 participants