Skip to content

Show the system window menu (Window::ShowSystemMenu) #66

Closed

Description

@lijy91

There's no API to show the system window menu (restore / move / size / minimize / maximize / close) at a point. Apps with a custom title bar need it for right-click on their drag area, and for Alt+Space on Windows. window_manager's popUpWindowMenu() is a no-op in 0.6.0 because of this.

Proposal: Window::ShowSystemMenu(Point). On Windows, GetSystemMenu + TrackPopupMenu, with the item states (restore/maximize enabled) kept correct. On Linux, gdk_window_show_window_menu(). On macOS, no equivalent (document it). Then DragToMoveArea in nativeapi-flutter can open it on secondary click.

Background:

Activity

  1. lijy91 commented on Oct 6, 2026

    @lijy91
    MemberAuthor

    Implemented in 286a96e (bindings: libnativeapi/nativeapi@33afd13).

    bool ShowSystemMenu(Point) plus a capability; the point is in content-area logical coordinates.

    • Windows: GetSystemMenu / TrackPopupMenuEx, keeping host custom items and WM_SYSCOMMAND behavior.
    • Linux: X11 verified through the real GDK protocol, C ABI, scale 1/2 and widget destruction. Wayland needs a real pointer press serial owned by the app and refuses otherwise.
    • Flutter: the secondary-tap path (5 widget tests).

    Still open: real menu selections on Windows (maximize, restore, minimize, close, custom item) with tools/gui/core_window_system_menu_test.ps1.

  2. lijy91 commented on Oct 7, 2026

    @lijy91
    MemberAuthor

    Real Windows verification done, with one bug found and fixed on the way.

    Core, real menu clicks (tools/gui/core_window_system_menu_test.ps1, Windows 11): 2/2 runs, 95 checks, 6 real owner-guarded selections — maximize, restore, minimize, restore from minimized, close and a host custom item — with the host's close state preserved and a destroyed window refusing the menu.

    Flutter end to end (tools/gui/flutter_window_title_bar_system_menu_test.ps1, flutter_window_title_bar_example) found a bug: DragToMoveArea opened the menu on the secondary press. On Windows the menu's modal loop then took the release, Flutter never saw it and ignored the next secondary click — the menu opened only once per window. Fixed in libnativeapi/nativeapi@a43ffb0: on Windows it now opens on the release, as a native title bar does; Linux keeps the press, which a Wayland compositor requires. ShowSystemMenu documents the timing (e21c922), with a widget test for the Windows release path.

    After the fix, on Windows 11 (Chinese UI; items are taken by their fixed order), 3/3 runs:

    Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions