mozilla / action-input Goto Github PK

I've been thinking about the general shape and major classes of the libraries so that we can being to feel out what work is on the developers and what work the libraries take on. It seems like the devs will need to do some up-front work declaring action maps and creating any custom filters or input sources. Hopefully, we can provide default action maps, filters, and input sources so that the dev just extends them with a little custom work.

Here's a rough list of work the dev does during development and then work the code does at runtime.

Please chime in if anything is missing, wrong, or needs tweaking.

During development

• extend types JSON (if any)
• extend action maps JSON
• code custom Filters (if any)
• code custom InputSources (if any)

At runtime

• instantiate ActionMaps from JSON
• instantiate Types from JSON
• instantiate Filters using the Types
• instantiate InputSources using the Types
• instantiate an ActionMapper with the ActionMaps, Filters, and InputSources
• instantiate an ActionManager with an ActionMapper
• subscribe to action events from the ActionManager
• poll the ActionManager during the game loop
• toggle ActionMaps based on:
  device changes: landscape, portrait, online, offline, ...
  mode changes: flat, portal, immersive
  situation changes: paused, playing, configuring

Here's an initial high-level description of a build system for discussion.

I'm using {project-name} until we decide on a name in the naming issue.

Tactics:

Write ES'15 syntax code into JS module files (one per class) and then build them into JS files for distribution.

Build using npm but do not require that projects using these libraries also use npm.

Use straight npm to call out to specific tools like webpack and docusaurus. So, no grunt or gulp.

Use webpack to generate JS files for each major library, as described in the README:

• {project name}-action.js
• {project name}-input.js
• {project name}-hardware.js
• {project-name}-config-ui.js

Also generate a single file for easy onboarding and for projects that need every library:

• {project name}-everything.js (a single file for single-inclusion quickstarts)

Also generate a minimized version of each file listed above.

Create build dirs for each library (action, input, hardware, config) that contain the JS and all library-specific data like JSON for the action maps, CSS for the config UI, and glTF for the controller models.

Create an 'everything' build dir with the {project-name}-everything.js and all of the library data mentioned above.

Documentation

Use docusaurus to generate JS API reference documents and an examples page.

Publish docs to this repo's GitHub Pages.

Not in this repo

• Large sample applications using these libraries (publish in separate repos for each Glitch publishing)

How should we go about getting / making info for the hardware that we want to support?

I was thinking that for each type of controller we would ideally have:

glTF models

left and right handed models of a consistent size (1u = 1M)

hardware control position metadata

the center position and plane of each button, pad, and stick.

pointing ray

on tracked hardware, the ray that is most naturally used to point

I think that @cvan mentioned that there have been previous conversations about this. Chris, do you know whether anyone started to gather these models?

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please see Mozilla-GitHub-Standards or email [email protected].

(Message COC001)

@cvan suggests Travis CI

I called the repo 'xr-input' to get us started, but @fernandojsg pointed out that this will be used outside of WebXR so 'xr' might be off-putting and confusing.

I'd like the name to be somewhat unique so that people can find it via a search engine.

So, add your name ideas on this Issue.

I would love to keep using https://github.com/Flet/semistandard as we do on aframe, what do you think?