Commit graph

5 commits

Author SHA1 Message Date
Alexandre Ardhuin ec1a015045
implicit-casts:false in dev (#45787) 2019-12-05 22:34:06 +01:00
Ian Hickson 449f4a6673
License update (#45373)
* Update project.pbxproj files to say Flutter rather than Chromium

Also, the templates now have an empty organization so that we don't cause people to give their apps a Flutter copyright.

* Update the copyright notice checker to require a standard notice on all files

* Update copyrights on Dart files. (This was a mechanical commit.)

* Fix weird license headers on Dart files that deviate from our conventions; relicense Shrine.

Some were already marked "The Flutter Authors", not clear why. Their
dates have been normalized. Some were missing the blank line after the
license. Some were randomly different in trivial ways for no apparent
reason (e.g. missing the trailing period).

* Clean up the copyrights in non-Dart files. (Manual edits.)

Also, make sure templates don't have copyrights.

* Fix some more ORGANIZATIONNAMEs
2019-11-27 15:04:02 -08:00
Greg Spencer f0978c225a
Game controller button support (#33868)
This adds support for game controller buttons. It adds some supplemental USB HID codes that aren't available from the Chromium source code, and maps those on Android to the game pad buttons that Android supports. Other platforms are not supported yet.
2019-06-05 16:23:17 -07:00
Francisco Magdaleno b70d260b3c
Adds the keyboard mapping for Linux (#29993) 2019-03-28 10:04:23 -07:00
Greg Spencer 2aad59314f
Add a keyboard key code generator. (#27620)
This adds a keycode generator that incorporates input from the Chromium and Android source trees, as well as some local tables, to generate static constants for the LogicalKeyboardKey and PhysicalKeyboardKey classes, as well as mappings from each of the platforms we support so far (currently only Android and Fuchsia).

This code generator parses the input files, generates an intermediate data structure (`key_data.json`) that is checked in, and then generates the Dart sources for these classes and some static maps that will also be checked in (but are not included in this PR).

The idea is that these codes don't change often, and so we don't need to generate them on every build, but we would like to be able to update them easily in the future if new data becomes available. If the existing data disappears or becomes unusable, we can maintain the checked-in data structure by hand if necessary, and still be able to generate the code.

This PR only contains the code generator, not the classes themselves. In another follow-on PR, I'll run the generator and check in the output of the generator.
2019-02-06 16:53:16 -08:00