Build key map DomCodeToKey() for Windows

ui/events/keycodes/key_map_win.h

+// 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 <map>
+
+#include "base/lazy_instance.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;
+
+struct KeyMapEntry {
+  DomCode code;

[dtapuska, 2016/02/04 20:31:45]

Why is code required here?

+  DomKey key;
+  KeyboardCode legacy_key_code;

[dtapuska, 2016/02/04 20:31:46]

I question storing this field whether it is required...

+  int flags;
+};
+typedef std::map<std::pair<DomCode, int /*flags*/>, KeyMapEntry> KeyMap;

[dtapuska, 2016/02/04 20:31:46]

can we get away with an unordered_map?

[chongz, 2016/02/04 21:10:25]

Not sure which one is better, the map will usually have 900 entries, and
LoadLayout() takes 20ms on my Win8 VM.

[Wez, 2016/02/09 00:18:57]

Unless we need ordering, and I don't think we do, I'd use unordered_map.

We can trim down the map by establishing a lookup order e.g. if we don't find an
entry for Code+Shift then we look up just Code and use that mapping, if present.

Since the map should never exceed ~1000 entries we should be able to reserve
buckets up-front and avoid reallocation & rehashing?

Rather than the KeyMapEntry struct, can we just store two maps, one from
Code+flags->Key and one from Code+flags->keyCode?

+
+class EVENTS_BASE_EXPORT WindowsKeyMap {
+ public:
+  // Create and load key map table with specified keyboard layout.
+  explicit WindowsKeyMap(HKL layout);
+
+  // Convert a DomCode to a DomKey for the layout specified in constructor.

[dtapuska, 2016/02/04 20:31:45]

We ideally should identify what |flags| are..

[chongz, 2016/02/04 21:10:25]

Ya I will add comment about EventFlags here

+  DomKey DomCodeToKey(DomCode code, int flags) const;
+
+  // Convert a DomCode to a legacy KeyboardCode.
+  KeyboardCode DomCodeToKeyboardCode(DomCode code) const;

[Wez, 2016/02/09 00:18:57]

Don't we need |flags| passing in to this? e.g. the same DomCode generates
VK_NUMPAD_5 or VK_CLEAR depending on the NumLock flag.

+
+  // Convert a legacy KeyboardCode to DomCode.
+  DomCode KeyboardCodeToDomCode(KeyboardCode key_code) const;

[Wez, 2016/02/09 00:18:57]

Is this used anywhere other than the test? If it's only for testing then name it
<foo>ForTest so that presubmit will trap any cases where it's used in non-test
code.

If it's used in non-test code then should it also output the necessary |flags|
for that particular DomCode to generate the desired |key_code| (see above)?

+
+  // Convert a DomCode to a DomKey for current system keyboard layout.
+  // Will reload key map table if the system layout has changed.
+  static DomKey DomCodeToSystemLayoutKey(DomCode code, int flags);
+
+ private:
+  friend struct base::DefaultLazyInstanceTraits<WindowsKeyMap>;
+
+  WindowsKeyMap();
+
+  void LoadLayout(HKL layout);

[Wez, 2016/02/09 00:18:57]

nit: Rename this UpdateLayout() and have it check whether |keyboard_layout_ ==
layout| and early-exit if so?

+  void AddKeyMapEntry(DomCode code,
+                      DomKey key,
+                      KeyboardCode legacy_key_code,
+                      int flags);
+
+  HKL keyboard_layout_;
+  KeyMap key_map_;
+
+  DISALLOW_COPY_AND_ASSIGN(WindowsKeyMap);
+};
+
+}  // namespace ui
+
+#endif  // UI_EVENTS_KEYCODES_KEY_MAP_WIN_H_