basalt-win32 0.0.0-rc5

package/native/win32/Win32MountingManager.h

@@ -0,0 +1,203 @@
+// The Windows mounting manager.
+//
+// `IMountingManager` is the one interface `ReactHost` requires in order to put
+// a surface on screen. Almost none of what that takes is here: the mutation
+// walk, the view registry, the event-emitter bookkeeping and the surface roots
+// are in `core/MountingWalk.h`, written once and shared with GTK and AppKit.
+// What is left below is the part that is genuinely Windows -- making a view,
+// parenting it, and turning a ShadowView into view state.
+//
+// Phase 19 made that division and tested it with a second platform. This is the
+// third, and it is the one that says whether the division holds or whether it
+// was two platforms happening to agree: GTK and AppKit are both toolkits with a
+// widget object per view, and this one is not.
+//
+// It holds. What is below is seven operations and a props translation, and the
+// only place Windows differs in kind rather than in spelling is that
+// `destroyView` has to actually delete -- there is no GObject refcount and no
+// ARC, so the registry's `unique_ptr`-shaped ownership is written out.
+
+#pragma once
+
+#include "RnWin32Image.h"
+#include "RnWin32View.h"
+#include "Win32ImageLoader.h"
+#include "Win32ScrollView.h"
+#include "Win32TextInput.h"
+
+#include "MountingWalk.h"
+
+#include <react/renderer/uimanager/IMountingManager.h>
+
+#include <functional>
+#include <string>
+#include <unordered_map>
+
+namespace basalt {
+
+class Win32MountingManager final : public facebook::react::IMountingManager,
+                                   public MountingWalk<Win32MountingManager, win32::RnWin32View *> {
+ public:
+
+  // The image loader, for the host to hand to React Native's
+  // `ImageLoaderModule` -- which is what `Image.getSize` and `Image.prefetch`
+  // reach. Shared so that module can hold a weak reference to it.
+  std::shared_ptr<win32::Win32ImageLoader> imageLoader() const { return imageLoader_; }
+  Win32MountingManager();
+  ~Win32MountingManager() noexcept override;
+
+  // --- IMountingManager -----------------------------------------------------
+
+  // Called on the JS thread, from the event loop's "update the rendering" step.
+  // Hands the transaction to the UI thread; does not touch a view.
+  void executeMount(facebook::react::SurfaceId surfaceId,
+                    facebook::react::MountingTransaction &&transaction) override;
+
+  void dispatchCommand(const facebook::react::ShadowView &shadowView,
+                       const std::string &commandName,
+                       const folly::dynamic &args) override;
+
+  facebook::react::ComponentRegistryFactory getComponentRegistryFactory() override;
+
+  bool hasComponent(const std::string &name) override;
+
+  // ReactCxxPlatform hands the UIManager to the mounting manager and to nothing
+  // else. Reanimated needs it, and is constructed from JavaScript where no host
+  // object is in reach, so this passes it on. See core/UIManagerAccess.h.
+  void setUIManager(std::weak_ptr<facebook::react::UIManager> uiManager) noexcept override;
+
+  // --- Host-facing ----------------------------------------------------------
+  //
+  // createSurfaceRoot, destroySurfaceRoot, getSurfaceRoot, viewForTag and
+  // eventEmitterForTag all come from MountingWalk.
+
+  // Applies a transaction to the view tree. Invoked on the UI thread by
+  // executeMount's marshalling -- not part of IMountingManager, and never to be
+  // called directly. Public because the posted work has to reach it, and
+  // because the tests call it rather than pumping a message loop.
+  void applyTransaction(facebook::react::SurfaceId surfaceId,
+                        facebook::react::MountingTransaction &&transaction);
+
+  // The UI-thread half of dispatchCommand, public for the same reason
+  // applyTransaction is.
+  void applyCommand(facebook::react::Tag tag,
+                    const std::string &commandName,
+                    const folly::dynamic &args);
+
+  // Called on the UI thread after every applied transaction, so the host can
+  // ask for a repaint.
+  //
+  // A callback rather than the manager knowing about a window, and needed at
+  // all because Windows repaints on demand: a mutation changes the view tree
+  // and nothing moves on screen until something invalidates. GTK reaches for
+  // `gtk_widget_queue_draw` and AppKit for `setNeedsDisplay:` from inside their
+  // own managers, which they can because a view there *is* a widget. Here a
+  // view is a plain object and only the host has the HWND.
+  void setOnDidMount(std::function<void()> onDidMount);
+
+  // The wheel. Finds the innermost <ScrollView> under a point in the surface
+  // root's coordinates and scrolls it, returning false when nothing there
+  // scrolls -- which is what lets the host hand the message to DefWindowProc.
+  //
+  // Routed through here rather than from the view layer because a Win32 view
+  // has no window of its own and there is no responder chain to walk: only the
+  // object that knows which tags are ScrollViews can decide. Deltas are pixels
+  // already; see Win32ScrollViewManager::kWheelStepPixels for how a notch
+  // becomes one.
+  bool scrollAt(win32::RnWin32View *root, double x, double y, double deltaX, double deltaY);
+
+  // --- <TextInput>, which needs more from a host than anything else ----------
+  //
+  // A text field's peer is a real EDIT control: a child window of the host's,
+  // whose notifications arrive at the host and whose colours are answered from
+  // the host's WM_CTLCOLOREDIT. None of those has an equivalent on GTK or
+  // AppKit, where a React Native view *is* a widget and the toolkit routes all
+  // of this on its own. See Win32TextInput.h.
+
+  // The window every peer is a child of. Must be set before the first
+  // TextInput mounts, which the host does right after creating its window.
+  void setHostWindow(HWND window);
+
+  // Moves every text field's peer to where its view now is. A child window does
+  // not follow a view that has no widget, so this has to be called after every
+  // transaction and after every scroll.
+  void syncTextInputBounds(win32::RnWin32View *root);
+
+  // WM_COMMAND and WM_CTLCOLOREDIT, forwarded from the host's window procedure.
+  bool handleControlCommand(WPARAM wparam, LPARAM lparam);
+  HBRUSH controlColor(HDC deviceContext, HWND control);
+
+  // BASALT_TEST_TYPE: real WM_CHARs into whichever field has focus.
+  bool typeIntoFocusedTextInput(const std::string &text);
+
+  // A press ended on this view. The one thing a painted control needs that a
+  // mounted one gets for free: a <Switch> on this host is drawn rather than
+  // being an HWND, so nothing under it turns a click into a toggle. Called by
+  // Win32TouchDispatcher, and a no-op for every view that is not a switch.
+  void pressedView(facebook::react::Tag tag);
+
+  // BASALT_TEST_TAP: focuses the field under a point, which is the one thing a
+  // synthesised tap cannot do -- a real click reaches the peer child window
+  // directly and never passes through the touch dispatcher at all.
+  bool focusTextInputAt(win32::RnWin32View *root, double x, double y);
+
+ private:
+  // --- What MountingWalk asks of a platform ---------------------------------
+  friend class MountingWalk<Win32MountingManager, win32::RnWin32View *>;
+
+  win32::RnWin32View *createView(const facebook::react::ShadowView &shadowView);
+  win32::RnWin32View *createRootView(facebook::react::Tag tag);
+  void destroyView(win32::RnWin32View *view);
+  void insertChild(win32::RnWin32View *parent, win32::RnWin32View *child, int index);
+  void removeChild(win32::RnWin32View *parent, win32::RnWin32View *child);
+  void updateView(win32::RnWin32View *view, const facebook::react::ShadowView &shadowView);
+  void forgetTag(facebook::react::Tag tag);
+
+  // --- The Windows half of updateView ---------------------------------------
+  void applyProps(win32::RnWin32View *view, const facebook::react::ShadowView &shadowView);
+  void applyText(win32::RnWin32View *view, const facebook::react::ShadowView &shadowView);
+  void applyImage(win32::RnWin32View *view, const facebook::react::ShadowView &shadowView);
+  void applyAccessibility(win32::RnWin32View *view, const facebook::react::ShadowView &shadowView);
+  void applyLayoutMetrics(win32::RnWin32View *view, const facebook::react::ShadowView &shadowView);
+  void applyScrollView(win32::RnWin32View *view, const facebook::react::ShadowView &shadowView);
+  void applyTextInput(win32::RnWin32View *view, const facebook::react::ShadowView &shadowView);
+
+  // The Windows half of a control, which on this host is painting rather than
+  // mounting -- see RnWin32View.h for why there is no widget to mount.
+  void applyControlPeer(win32::RnWin32View *view, const basalt::ControlState &state);
+
+  // React DevTools' overlay rectangles. The parsing and the clearing are in
+  // MountingWalk; this is the drawing.
+  void setHighlights(win32::RnWin32View *view,
+                     const std::vector<basalt::Highlight> &highlights);
+
+  // The source each <Image> is currently showing, so that a mutation which
+  // changed only layout does not restart the load and make the image flicker
+  // whenever its parent resizes. Both other platforms keep the same map.
+  std::unordered_map<facebook::react::Tag, std::string> imageUris_;
+
+  // Scroll offsets, the unthrottled state write-back, the wheel and the
+  // commands. Constructed with a lookup into this object's own emitter registry
+  // rather than a second copy of it.
+  Win32ScrollViewManager scrollViews_;
+
+  // The EDIT peers, their placement, the controlled-value loop and the
+  // commands. Same lookup, same reason.
+  Win32TextInputManager textInputs_;
+
+  // Fetching and decoding, off the UI thread. Holds the decoded-pixel cache
+  // too, and outlives this object while a load is in flight -- see the header.
+  // Shared rather than held by value: React Native's `ImageLoaderModule` takes
+  // a `weak_ptr<IImageLoader>`, and this is the loader it gets.
+  std::shared_ptr<win32::Win32ImageLoader> imageLoader_ =
+      std::make_shared<win32::Win32ImageLoader>();
+
+  // A <Switch> is a controlled component: the drawing is not allowed to decide
+  // its own state, so the value React last sent is kept here and the view is
+  // repainted from it after the click that told JavaScript about it.
+  std::unordered_map<facebook::react::Tag, bool> switchValues_;
+
+  std::function<void()> onDidMount_;
+};
+
+} // namespace basalt

package/native/win32/Win32Packaging.cpp

@@ -0,0 +1,161 @@
+#include "Win32Packaging.h"
+
+#include "AppIdentity.h"
+#include "Win32Strings.h"
+
+#include <windows.h>
+
+#include <knownfolders.h>
+#include <objbase.h>
+#include <propkey.h>
+#include <propsys.h>
+#include <propvarutil.h>
+#include <shlobj.h>
+#include <shobjidl.h>
+
+#include <string>
+
+namespace basalt::win32 {
+
+namespace {
+
+std::wstring &applied() {
+  static std::wstring id;
+  return id;
+}
+
+// Where a per-user Start Menu shortcut goes. Per-user rather than per-machine
+// because this is not an installer: writing into the all-users Start Menu needs
+// administrator rights, and an app being run from a build directory has no
+// business asking for them.
+std::wstring startMenuShortcutPath(const std::wstring &name) {
+  PWSTR folder = nullptr;
+  if (FAILED(SHGetKnownFolderPath(FOLDERID_Programs, 0, nullptr, &folder))) {
+    return {};
+  }
+  std::wstring path(folder);
+  CoTaskMemFree(folder);
+  path += L"\\";
+  path += name;
+  path += L".lnk";
+  return path;
+}
+
+// The executable this process was started from, which is what the shortcut has
+// to point at.
+std::wstring executablePath() {
+  std::wstring path(MAX_PATH, L'\0');
+  while (true) {
+    const DWORD written = GetModuleFileNameW(nullptr, path.data(), static_cast<DWORD>(path.size()));
+    if (written == 0) {
+      return {};
+    }
+    if (written < path.size()) {
+      path.resize(written);
+      return path;
+    }
+    // Truncated. The only way to know is that it filled the buffer, so grow and
+    // ask again rather than shipping a path that is quietly half a path.
+    path.resize(path.size() * 2);
+  }
+}
+
+// Writes the shortcut, with the AppUserModelID on it. Returns false on any
+// failure, all of which are survivable: what is lost is notifications, not the
+// app.
+bool writeShortcut(const std::wstring &shortcutPath,
+                   const std::wstring &target,
+                   const std::wstring &id) {
+  IShellLinkW *link = nullptr;
+  if (FAILED(CoCreateInstance(
+          CLSID_ShellLink, nullptr, CLSCTX_INPROC_SERVER, IID_IShellLinkW, (void **)&link))) {
+    return false;
+  }
+
+  bool ok = SUCCEEDED(link->SetPath(target.c_str()));
+  if (ok) {
+    // The working directory matters: the host resolves its bundle relative to
+    // wherever it was started, so a shortcut with the wrong one launches an app
+    // that cannot find its JavaScript.
+    const size_t slash = target.find_last_of(L'\\');
+    if (slash != std::wstring::npos) {
+      link->SetWorkingDirectory(target.substr(0, slash).c_str());
+    }
+  }
+
+  // The property that makes the whole thing work. A shortcut without it is
+  // just a shortcut, and the shell goes on refusing to show notifications for
+  // this id.
+  if (ok) {
+    IPropertyStore *properties = nullptr;
+    ok = SUCCEEDED(link->QueryInterface(IID_IPropertyStore, (void **)&properties));
+    if (ok) {
+      PROPVARIANT value;
+      ok = SUCCEEDED(InitPropVariantFromString(id.c_str(), &value));
+      if (ok) {
+        ok = SUCCEEDED(properties->SetValue(PKEY_AppUserModel_ID, value));
+        if (ok) {
+          ok = SUCCEEDED(properties->Commit());
+        }
+        PropVariantClear(&value);
+      }
+      properties->Release();
+    }
+  }
+
+  if (ok) {
+    IPersistFile *file = nullptr;
+    ok = SUCCEEDED(link->QueryInterface(IID_IPersistFile, (void **)&file));
+    if (ok) {
+      ok = SUCCEEDED(file->Save(shortcutPath.c_str(), TRUE));
+      file->Release();
+    }
+  }
+
+  link->Release();
+  return ok;
+}
+
+} // namespace
+
+void applyPackaging(const AppIdentity &identity) {
+  if (identity.empty()) {
+    return;
+  }
+
+  const std::wstring id = widen(identity.identifier);
+  // Before any window. The shell reads this when a window is first shown and
+  // does not notice a later change, which is why this is called from the top of
+  // the host rather than from wherever notifications are first used.
+  if (FAILED(SetCurrentProcessExplicitAppUserModelID(id.c_str()))) {
+    return;
+  }
+  applied() = id;
+
+  const std::wstring name = widen(identity.name.empty() ? identity.identifier : identity.name);
+  const std::wstring shortcut = startMenuShortcutPath(name);
+  if (shortcut.empty()) {
+    return;
+  }
+  // Left alone once written. This is a real file in the person's Start Menu,
+  // and a development session that rewrote it on every run would churn their
+  // menu for nothing.
+  if (GetFileAttributesW(shortcut.c_str()) != INVALID_FILE_ATTRIBUTES) {
+    return;
+  }
+  const std::wstring target = executablePath();
+  if (target.empty()) {
+    return;
+  }
+  writeShortcut(shortcut, target, id);
+}
+
+bool hasAppUserModelId() {
+  return !applied().empty();
+}
+
+const wchar_t *appUserModelId() {
+  return applied().c_str();
+}
+
+} // namespace basalt::win32

package/native/win32/Win32Packaging.h

@@ -0,0 +1,56 @@
+// Making this process look like an installed application to Windows.
+//
+// Unlike macOS, nothing here is about where the executable sits: Windows has no
+// bundle. What it has is an **AppUserModelID**, a string the shell uses to
+// decide which taskbar button a window belongs to, which jump list it has, and
+// -- the reason this file exists -- which application a notification came from.
+//
+// A desktop application that wants to raise a notification has to do two things,
+// and doing only one of them fails silently:
+//
+//   1. Call `SetCurrentProcessExplicitAppUserModelID` before it shows any UI.
+//      Without it the shell derives an id from the process, which changes
+//      between a run from a build directory and a run from anywhere else.
+//
+//   2. Have a Start Menu shortcut whose `System.AppUserModel.ID` property is
+//      that same string. This is the part people miss. The shell will not
+//      surface a notification for an id it has never seen installed, and a
+//      shortcut is how an id becomes installed. Microsoft's own toast
+//      documentation says so, and it is why this is in the host rather than in
+//      `cli/packageApp.js`: setting that property means `IPropertyStore`, which
+//      is COM, and doing it in C++ at startup is simpler and more reliable than
+//      doing it in PowerShell from Node.
+//
+// Both are driven from `core/AppIdentity.h`, which the CLI writes beside the
+// bundle. An app with no identity file gets neither, and notifications then
+// report that they are unavailable -- which is the answer this host gave before
+// any of this existed.
+//
+// The shortcut is written once and left alone. It is a real file in the
+// person's Start Menu, so rewriting it on every run would mean a development
+// session churning their menu; `ensureStartMenuShortcut` checks first.
+
+#pragma once
+
+namespace basalt {
+
+struct AppIdentity;
+
+namespace win32 {
+
+// Applies the identity to this process: the AppUserModelID, and a Start Menu
+// shortcut carrying it if there is not one already.
+//
+// Call once, from the host, before any window exists. A no-op for an empty
+// identity.
+void applyPackaging(const AppIdentity &identity);
+
+// Whether this process has an AppUserModelID, which is what decides whether a
+// notification can be raised at all. Read by Win32Notifications.cpp.
+bool hasAppUserModelId();
+
+// The identity's id, as applied. Empty when none was.
+const wchar_t *appUserModelId();
+
+} // namespace win32
+} // namespace basalt

package/native/win32/Win32RunLoopObserver.cpp

@@ -0,0 +1,48 @@
+#include "Win32RunLoopObserver.h"
+
+#include <windows.h>
+
+#include <react/utils/RunLoopObserverManager.h>
+
+namespace basalt {
+
+int runMessageLoopWithBeat(
+    std::shared_ptr<facebook::react::RunLoopObserverManager> manager) {
+  MSG message{};
+  for (;;) {
+    // Drain everything queued before beating. Beating between each message
+    // would be correct but wasteful, and beating *after* the queue is empty is
+    // what "BeforeWaiting" means -- the frame has settled, and whatever the
+    // messages produced is now worth flushing to JavaScript in one go.
+    while (PeekMessageW(&message, nullptr, 0, 0, PM_REMOVE)) {
+      if (message.message == WM_QUIT) {
+        return static_cast<int>(message.wParam);
+      }
+      TranslateMessage(&message);
+      DispatchMessageW(&message);
+    }
+
+    if (manager != nullptr) {
+      manager->onRender();
+    }
+
+    // Block until something arrives. MsgWaitForMultipleObjectsEx rather than
+    // GetMessage, because the beat above may itself have posted work -- a mount
+    // marshalled from the JS thread arrives as a posted message -- and
+    // GetMessage would be fine, but this is the form that also takes handles
+    // when something later needs to wait on one.
+    //
+    // MWMO_INPUTAVAILABLE matters and is easy to omit: without it, a message
+    // that was already in the queue when the wait begins does not count as an
+    // event, and the loop sleeps with work pending until the *next* message
+    // arrives. With PeekMessage above having just emptied the queue that is
+    // nearly always fine, and "nearly always" is how an app hangs once an hour.
+    const DWORD result =
+        MsgWaitForMultipleObjectsEx(0, nullptr, INFINITE, QS_ALLINPUT, MWMO_INPUTAVAILABLE);
+    if (result == WAIT_FAILED) {
+      return 1;
+    }
+  }
+}
+
+} // namespace basalt

package/native/win32/Win32RunLoopObserver.h

@@ -0,0 +1,42 @@
+// Driving React Native's event beat from the message loop.
+//
+// Nothing an EventEmitter produces reaches JavaScript on its own.
+// `EventQueue::onEnqueue` only sets a flag on the EventBeat; the queue is
+// flushed when something calls `RunLoopObserverManager::onRender()`, which
+// induces the beat. Until that is wired, touches are enqueued and silently
+// never delivered -- which looks like an input bug and is not one.
+//
+// What React Native asks for is `Activity::BeforeWaiting`: run once the loop
+// has drained its work and is about to sleep. The three platforms get there
+// differently, and Windows is the one where it cannot be *installed*.
+//
+//   iOS/macOS   a CFRunLoopObserver on kCFRunLoopBeforeWaiting
+//   GTK         a GSource whose prepare() does the work and never reports ready
+//   Win32       no hook exists, so the loop itself has to be written
+//
+// A Win32 message loop is `GetMessage`/`DispatchMessage`, and there is no
+// callback for "about to block". The equivalent is to stop using `GetMessage`:
+// drain with `PeekMessage` until it comes up empty, beat, and only then block
+// in `MsgWaitForMultipleObjectsEx`. That is exactly "having drained whatever
+// else was pending", and blocking properly rather than polling is what keeps an
+// idle app at zero CPU -- which was the objection to `gtk_widget_add_tick_callback`
+// recorded in `docs/DECISIONS.md`, and applies here for the same reason.
+//
+// So this is a loop rather than an observer, and the host calls it instead of
+// writing its own.
+
+#pragma once
+
+#include <memory>
+
+namespace facebook::react {
+class RunLoopObserverManager;
+}
+
+namespace basalt {
+
+// Runs until WM_QUIT, inducing the beat each time the queue empties. Returns
+// the exit code from WM_QUIT.
+int runMessageLoopWithBeat(std::shared_ptr<facebook::react::RunLoopObserverManager> manager);
+
+} // namespace basalt