sinisterchipmunk / jax

Framework for creating rich WebGL-enabled applications using JavaScript and Ruby
http://jaxgl.com
MIT License
96 stars 16 forks source link

input actions in controllers #64

Closed MichaelHoste closed 11 years ago

MichaelHoste commented 12 years ago

After I updated to Jax 3.0RC1 on my project, the "key_pressed" action of my controller didn't seem to work anymore (alert() at the beginning of the controller and no result after pressing a key).

I tried the demo page related to input actions (http://docs.jaxgl.com/using-mouse-to-interact-with-models.html) with Firefox 15 and Chrome 22 on MacOS.

sinisterchipmunk commented 12 years ago

I've been looking into this, but going to leave it alone for the most part until #63 is fixed, since it looks like one may impact the other.

sinisterchipmunk commented 12 years ago

This is actually 3 separate issues. I might split them apart and fix them separately. If I do that, I'll be sure to reference this issue for trackability.

I can reproduce the picking and unprojection issues on my machine. I am still looking into the keyboard input. I don't believe this is related to #63 any more.

sinisterchipmunk commented 12 years ago

The last several commits (2f1c79675b566bf13dac62f429d1f13b26b83d92, 1e25f44dbb418ff52cc768b03912ab8f76caa734, b7f7c639a05c3171c4aefa1fdb523af2f6a91402, de16067832db2f7caca68e032b4adba2d3647761) appear to resolve all current issues with picking on my dev machine.

The changes will have no effect on the other two outstanding issues, unprojection and keyboard input. Also, the docs examples have not yet been rebuilt with the new code.

sinisterchipmunk commented 11 years ago

6e358798f1c6ec036b8d6ce626b21d8941a3f76e resolves mouse event handling on FF and does not appear to break on Chrome.

sinisterchipmunk commented 11 years ago

@MichaelHoste Keyboard input was redesigned in Jax 3 to be less intrusive. Jax 2 hooked into keyboard events at the document level, and attempted to explicitly whitelist various key-receiving elements (e.g. text boxes). This caused a number of problems, not least of which pertained to handling keyboard input with multiple Jax contexts on the same page.

In Jax 3, keyboard events are hooked directly into the underlying <canvas/> element. During keyboard event initialization, a tab index is assigned (unless it already has one) and this should be enough in both FF and Chrome to allow the element to receive input.

In my test environment, I can click on the <canvas/> element and then start using the keyboard. I can also programmatically focus the element with document.getElementsByName("canvas")[0].focus() and then receive keyboard input.

Please tell me if doing the above resolves the issue for you. If so, then it is by design. If you have to take any other steps or if the above steps don't work at all, then this is still an issue.

MichaelHoste commented 11 years ago

Again, you are totally right. I didn't realize that the keyboard inputs were redesigned to behave like this. When I focused on the canvas, the keyboard inputs started to work !

It was difficult for me to catch this because I use Jax in a very specific situation where the display was rendered with RaphaelJS (2D) or WebGL (3D). The user has the choice. Since WebGL doesn't work anymore in my config (#63), I only could try RaphaelJS. The result is that the WebGL canvas is not displayed and the input could not be triggered.

Now that I understand the situation, I know how to make it work on RaphaelJS (force the focus on a small hidden WebGL canvas).

Thanks again !

sinisterchipmunk commented 11 years ago

I was concerned that you were encountering another issue, so this is great news!

That means all 3 of the input-related issues in this thread have been solved. Closing.

FYI, this discussion has prompted me to add a new issue, #70, relating to using Jax without a renderer.

Further FYI, Jax 3 introduces basic multiple renderer support, such that if one renderer doesn't work, the next one in the line will be used, until all options are exhausted. It currently only adds a WebGL renderer by default and frankly I'm not sure whether adding another renderer will actually work or not; it was more about setting the stage for multiple renderers down the road in v3.1, and currently represents a sort of hybrid between single- and multi- renderer. But, if you want to try your luck with it, I'd be eager to read your findings!

EDIT: There's no documentation yet on the renderers or how they work; see jax/renderer.js.coffee and jax/renderers/webgl.js.coffee for the existing sources, as well as jax/context.js.coffee:202 for how they are instantiated.