Feature: More customizable pointer events for advanced use cases

[hmpthz]

It's always been hard if there are interactive childs inside Viewport containers.
Devs have to be careful with all those event bubbling and capturing stuff to make things work as they expect.

Recently, I was adding a few childs with 'pointertap' events into Viewport, hoping the child events would be emitted before Viewport events. Then I found out 'pointertap' event was not added by InputManager, therefore event bubbling didn't work.

This makes me think if it's a good idea to provide additional options for devs to fully control Viewport's pointer events. I believe it might be useful in some rare use cases.

This commit adds a new property to IViewportOption. People won't notice any difference if this prop is not specified.

[danielbarion]

@hmpthz we'll be taking a look as soon as possible, thanks!

[danielbarion]

@hmpthz can you please check the conflicts?

[danielbarion]

@hmpthz @davidfig I believe we should release v6 and after it, check this PR and release a v6.1.0 after confirming everything is working as expected :)

[hmpthz]

@danielbarion Thanks, I'm looking into it. It seems the conflicts are just about imports.

[hmpthz]

@hmpthz @davidfig I believe we should release v6 and after it, check this PR and release a v6.1.0 after confirming everything is working as expected :)

Conflict resolved, please check :)

[danielbarion]

the code looks good to me, but I would like to have feedback from @lunarraid too.

@lunarraid can you please take a look and let me know your thoughts about it? thanks in advance

[lunarraid]

This seems to add a lot of complexity just to change out whether or not the pointer events use the capture phase or not. Is all that per-event logic really necessary? There's nothing preventing devs from simply adding their own capture phase events for any reason they'd need to without any API changes.

[hmpthz]

Hi @lunarraid the main reason for this pr is because you can't stop the original InputManager from adding all default listeners in constructor.
Therefore, if you want to change to a different event, you must remove the current one first. I just feel like this "remove then add again" can be avoided by a new config option.
But you have the point that this would be an overkill as devs are free to add events they want anyway.

An alternative solution could be a simple boolean option such as "noDefaultListeners" so that InputManager won't add anything in contructor. Then it'll be devs jobs to add things on their demand. Do you think this sounds ok?

if (!this.viewport.options.noDefaultListeners)
{
    this.addPointerListeners();
}

Frankly speaking, writing some "remove then add again" code doesn't hurt anything. It's just my personal motive to get rid of it at the cost of a small API change.