basalt-gtk 0.0.0-rc5

package/native/gtk/GtkKeyEvents.cpp

@@ -0,0 +1,91 @@
+#include "GtkKeyEvents.h"
+
+#include <glib.h>
+
+#include <string>
+
+namespace basalt {
+namespace {
+
+const char *specialNameFor(guint keyval) {
+  switch (keyval) {
+  case GDK_KEY_Up:
+  case GDK_KEY_KP_Up:
+    return kKeyArrowUp;
+  case GDK_KEY_Down:
+  case GDK_KEY_KP_Down:
+    return kKeyArrowDown;
+  case GDK_KEY_Left:
+  case GDK_KEY_KP_Left:
+    return kKeyArrowLeft;
+  case GDK_KEY_Right:
+  case GDK_KEY_KP_Right:
+    return kKeyArrowRight;
+  case GDK_KEY_Page_Up:
+  case GDK_KEY_KP_Page_Up:
+    return kKeyPageUp;
+  case GDK_KEY_Page_Down:
+  case GDK_KEY_KP_Page_Down:
+    return kKeyPageDown;
+  case GDK_KEY_Home:
+  case GDK_KEY_KP_Home:
+    return kKeyHome;
+  case GDK_KEY_End:
+  case GDK_KEY_KP_End:
+    return kKeyEnd;
+  case GDK_KEY_Delete:
+  case GDK_KEY_KP_Delete:
+    return kKeyDelete;
+  case GDK_KEY_BackSpace:
+    return kKeyBackspace;
+  case GDK_KEY_Return:
+  case GDK_KEY_KP_Enter:
+    return kKeyEnter;
+  case GDK_KEY_Tab:
+  // Shift-Tab is its own keyval here, as back-tab is its own character on
+  // AppKit. Reported as Tab with shift set, for the same reason: that is what a
+  // browser reports and what an app will have bound.
+  case GDK_KEY_ISO_Left_Tab:
+    return kKeyTab;
+  case GDK_KEY_Escape:
+    return kKeyEscape;
+  default:
+    return nullptr;
+  }
+}
+
+} // namespace
+
+std::optional<KeyCombination> keyCombinationFrom(guint keyval, GdkModifierType state) {
+  KeyModifiers modifiers;
+  modifiers.alt = (state & GDK_ALT_MASK) != 0;
+  modifiers.ctrl = (state & GDK_CONTROL_MASK) != 0;
+  // Super is `meta`. W3C names the Windows and Command keys Meta, and this is the
+  // key in that position on a Linux keyboard -- so an app that binds metaKey gets
+  // the same physical key on all three desktops. GDK_META_MASK is a different
+  // key again on X11, historically the one next to Alt, and almost nothing has
+  // one; mapping it here would give an app a modifier it cannot press.
+  modifiers.meta = (state & GDK_SUPER_MASK) != 0;
+  modifiers.shift = (state & GDK_SHIFT_MASK) != 0;
+
+  if (const char *special = specialNameFor(keyval)) {
+    return KeyCombination{std::string(special), modifiers};
+  }
+
+  // A keyval already accounts for Shift -- `A` and `a` are different keyvals --
+  // so case follows the character here without doing anything, which is what a
+  // browser reports and what AppKit needs `characters` for.
+  const guint32 codepoint = gdk_keyval_to_unicode(keyval);
+  if (codepoint == 0) {
+    // A bare modifier, or a keyval with no character and no name of ours.
+    return std::nullopt;
+  }
+  char utf8[8] = {};
+  const gint length = g_unichar_to_utf8(static_cast<gunichar>(codepoint), utf8);
+  if (length <= 0) {
+    return std::nullopt;
+  }
+  return KeyCombination{std::string(utf8, static_cast<size_t>(length)), modifiers};
+}
+
+} // namespace basalt

package/native/gtk/GtkKeyEvents.h

@@ -0,0 +1,21 @@
+// A GDK key press as a key combination, in core/KeyEvents.h's vocabulary.
+//
+// The GTK counterpart of appkit/AppKitKeyEvents.h, and deliberately not shared
+// with it: a keyval is not an NSEvent and the two have nothing in common but the
+// names they produce -- which is exactly why those names are constants in core.
+
+#pragma once
+
+#include "KeyEvents.h"
+
+#include <gtk/gtk.h>
+
+#include <optional>
+
+namespace basalt {
+
+// Nothing for a press with no key to speak of: a bare modifier, or a keyval that
+// maps to no character and no name.
+std::optional<KeyCombination> keyCombinationFrom(guint keyval, GdkModifierType state);
+
+} // namespace basalt

package/native/gtk/GtkMenuBar.cpp

@@ -0,0 +1,45 @@
+// The Linux half of core/MenuModel.h: no application menu, and why.
+//
+// This is not unimplemented. GNOME's guidelines have said since GNOME 3 that an
+// application should use a header bar with a menu button rather than a menu
+// bar, GTK4 removed `GtkMenuBar` along with the rest of GtkMenu, and this
+// host's window already has a header bar -- which is where a GTK app's menu
+// belongs and which `<TitleBar>` already lets an app fill.
+//
+// Answering `applicationMenuSupported() == false` is the honest reply, and it
+// is the reason that function exists: an app can ask, put its commands in its
+// own header, and ship something a GNOME user recognises, rather than shipping
+// a File menu nobody on Linux can see.
+//
+// What Linux does *not* lack is menus. `showMenu` in PlatformServicesGtk.cpp is
+// a real GtkPopoverMenu, and it is what a header-bar menu button opens; the
+// developer menu already uses it. What is missing is only the bar.
+//
+// If this ever changes, the shape to build is `GtkPopoverMenuBar` over a
+// `GMenuModel`, packed above the surface root -- which is a layout change to
+// the window rather than an addition to this file, because the surface would
+// no longer start at the top of the content area.
+
+#include "MenuModel.h"
+
+#include <string>
+
+namespace basalt {
+
+bool applicationMenuSupported() {
+  return false;
+}
+
+std::string describeApplicationMenu() {
+  // Nothing is installed, so there is nothing to describe. The empty string is
+  // what a test asserting "this platform has no menu bar" reads.
+  return {};
+}
+
+void setApplicationMenu(const MenuModel & /*menu*/, std::function<void(int)> /*onChosen*/) {
+  // Deliberately nothing. An app that checked `applicationMenuSupported()`
+  // already knows; one that did not is no worse off than before it described a
+  // menu, and a warning on every render would be noise it cannot act on.
+}
+
+} // namespace basalt