Debug mouse block

[Geokureli]

A change to a very core feature, would like to discuss before merging. right now openfl display objects above the game don't block Flixel mouse events, including FlxDebugger ui. I submit that they should, and this will accomplish that by adding listeners to a child of the FlxGame rather than the stage.

related to #2155

[MSGhero]

I didn't check discord thoroughly, but are the stage's mouse events "unpreventable" on Flash too? I ask because if they're not, then that's something lacking on the OpenFL side (I added preventDefault support to several events, but not all of them that need it).

[Geokureli]

it's not that you can't preventDefault, but you cannot mouse block a FlxGame by putting a mouseEnabled displayObject in front of it.

[Geokureli]

Also: this might be unrelated, but right now HaxeFlixel assumes that the FlxGame is the only DisplayObject in a game, it always takes up the entire game screen and it's always listening to mouse and keyboard events. it may be desired to have other, non-HaxeFlixel elements around or over the FlxGame, like how my dial-a-platformer gadget uses a swf UI over the FlxGame.

For instance, it would be great if I could make my openfl project larger than the FlxGame's stage bounds so that the FlxDebugger isn't covering up the entire game

[Gama11]

Have you seen that there's already a PR for that issue?

#2209

[Geokureli]

@Gama11 That issue is for disabling Flixel mouse events when interacting with the FlxGame while interactive debugger tools are active. this change is for blocking mouse events when interacting with Display Objects above the FlxGame. the two are pretty related, but they are different features. I guess i tried to piggy back this to that existing issue, and perhaps I should make a new issue?

[Gama11]

right now openfl display objects above the game don't block Flixel mouse events, including FlxDebugger ui.

Could you elaborate on that? I seem to be unable to click a FlxButton through a debugger window, both on Neko and Flash. I think there's special code that disables FlxG.mouse while the mouse is over debugger UI.

As for display objects added by the user, it seems like it should be up to the user whether he wants to allow "click-through" or not? There might already be games that rely on the current behavior.

[Geokureli]

I tested on my current project and you are correct, I was unable to click a FlxButton through the debugger windows, but on the Mode Demo I am able to cancel the replay by clicking on a debugger window. I don't yet know the difference, here, but I noticed that the replay's cancel keys is set to ALL. Thats how I first noticed this issue, I was attempting to use the debugger windows during a replay.

When I wrote this PR, I was under the impression that all mouse "details" were permeating openfl display objects above the FlxGame. This was never the case apparently.

I'll report back with better details of what is changed, here and reanalyze whether I think this change is necessary.

As for allowing the user to decide whether click-through is available: On dev, I do not have a choice as to whether the replay is canceled when debug windows are clicked, but with my change I can control that by setting the debug layer's mouseEnabled to false. However, with this branch's changes there will not be a way to have a single click affect the debug window and cancel the replay. That would be possible with the method you describe, where FlxMouse is disabled based on its interaction with other displayObjects

[Gama11]

I wasn't aware of that replay/debugger interaction, seems like an oversight.

[Gama11]

I'll close here for now, as it sounds like this was a replay-specific issue and needs to be addressed differently.