Build key map DomCodeToKey() for Windows

ui/events/keycodes/key_map_win.h

Index: ui/events/keycodes/key_map_win.h
diff --git a/ui/events/keycodes/key_map_win.h b/ui/events/keycodes/key_map_win.h
new file mode 100644
index 0000000000000000000000000000000000000000..4b0442b6d685dd93b25bccc4f722ebad89664665
--- /dev/null
+++ b/ui/events/keycodes/key_map_win.h
@@ -0,0 +1,54 @@
+// Copyright (c) 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef UI_EVENTS_KEYCODES_KEY_MAP_WIN_H_
+#define UI_EVENTS_KEYCODES_KEY_MAP_WIN_H_
+
+#include <windows.h>
+
+#include <unordered_map>
+
+#include "base/hash.h"
+#include "ui/events/events_base_export.h"
+#include "ui/events/keycodes/dom/dom_key.h"
+#include "ui/events/keycodes/keyboard_codes_win.h"
+
+namespace ui {
+
+enum class DomCode;
+
+typedef std::unordered_map<std::pair<int /*DomCode*/, int /*EventFlags*/>,

[Wez, 2016/02/11 23:14:45]

Why use an int here rather than DomCode?

Feels like it would be cleaner to typedef the pair<DomCode,flags> to some
helpful name and then typedef the unordered_map to work with that.

Can this typedef be moved inside the WindowsKeyMap, so that it's not defined at
the top-level of the ui namespace?

Finally, KeyMap is a very generic name; this specific map is a DomCodeToKey map,
effectively.  You wouldn't use it e.g. to map from Key to Code or Code to
KeyboardCode, for example.

+                           DomKey,
+                           base::IntPairHash<std::pair<int, int>>>
+    KeyMap;
+
+class EVENTS_BASE_EXPORT WindowsKeyMap {

[Wez, 2016/02/11 23:14:45]

nit: Aside from the explicit HKL constructor, the API of this class isn't
actually OS-specific - it maps from generic DomCode+ui::EventFlags to DomKey,
and the static API doesn't even require the Windows-specific HKL to be
specified, so should we call this PlatformKeyMap in case we decided to add Linux
or Mac equivalents later?

+ public:
+  // Create and load key map table with specified keyboard layout.
+  explicit WindowsKeyMap(HKL layout) : keyboard_layout_(0) {

[Wez, 2016/02/11 23:14:45]

As per style-guide, don't declare method bodies inline, except for trivial
getters/setters.

+    UpdateLayout(layout);
+  }
+
+  // Convert a DomCode + flags to a DomKey for layout specified in constructor.
+  DomKey DomCodeAndFlagsToDomKey(DomCode code, int flags /*EventFlags*/) const;
+
+  // Convert a DomCode + flags to a DomKey using the layout for current thread.
+  // Will load/update key map table in first call or when layout has changed.
+  static DomKey DomCodeAndFlagsToDomKeyStatic(DomCode code,
+                                              int flags /*EventFlags*/);

[Wez, 2016/02/11 23:14:45]

I'd suggest renaming flags -> event_flags or even ui_event_flags and updating
the comment to say something like "Returns the DomKey 'meaning' of |code| in the
context of specified |ui_event_flags|."

+
+ private:
+  WindowsKeyMap() : keyboard_layout_(0) {}

[Wez, 2016/02/11 23:14:45]

See above re inlining.

+
+  void UpdateLayout(HKL layout);
+
+  HKL keyboard_layout_;

[Wez, 2016/02/11 23:14:45]

This can use C++11 inline initialization:

  HKL keyboard_layout_ = 0;

so that you don't need to initialize it explicitly in the constructor.

+  KeyMap key_map_;
+
+  DISALLOW_COPY_AND_ASSIGN(WindowsKeyMap);
+};
+
+}  // namespace ui
+
+#endif  // UI_EVENTS_KEYCODES_KEY_MAP_WIN_H_