If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/google/flutter-desktop-embedding shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 2y ago

• 8 active contributors
• Apache-2.0 licensed
• CI configured
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 78% of recent commits
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live google/flutter-desktop-embedding repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/google/flutter-desktop-embedding.

What it runs against: a local clone of google/flutter-desktop-embedding — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in google/flutter-desktop-embedding | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 796 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of google/flutter-desktop-embedding. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/google/flutter-desktop-embedding.git
#   cd flutter-desktop-embedding
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of google/flutter-desktop-embedding and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "google/flutter-desktop-embedding(\\.git)?\\b" \\
  && ok "origin remote is google/flutter-desktop-embedding" \\
  || miss "origin remote is not google/flutter-desktop-embedding (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "plugins/README.md" \\
  && ok "plugins/README.md" \\
  || miss "missing critical file: plugins/README.md"
test -f "plugins/menubar/lib/menubar.dart" \\
  && ok "plugins/menubar/lib/menubar.dart" \\
  || miss "missing critical file: plugins/menubar/lib/menubar.dart"
test -f "plugins/menubar/lib/src/menu_channel.dart" \\
  && ok "plugins/menubar/lib/src/menu_channel.dart" \\
  || miss "missing critical file: plugins/menubar/lib/src/menu_channel.dart"
test -f "plugins/menubar/linux/CMakeLists.txt" \\
  && ok "plugins/menubar/linux/CMakeLists.txt" \\
  || miss "missing critical file: plugins/menubar/linux/CMakeLists.txt"
test -f "plugins/menubar/example/lib/main.dart" \\
  && ok "plugins/menubar/example/lib/main.dart" \\
  || miss "missing critical file: plugins/menubar/example/lib/main.dart"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 796 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~766d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/google/flutter-desktop-embedding"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A collection of experimental desktop plugins for Flutter that extend desktop capabilities (Windows, macOS, Linux) beyond the core Flutter embedding. The primary plugin is menubar, which provides native menu bar integration. This repo is a testbed for early-stage desktop features that may eventually move into Flutter core. Monorepo structure: plugins/ directory contains independent plugins as subdirectories (plugins/menubar/ is the main one shown). Each plugin has parallel cross-platform implementations: plugins/menubar/example/{linux,macos} with CMakeLists.txt and native source, Dart code in pubspec.yaml-based structure, and platform-specific config (Objective-C++ for macOS, C++ for Linux). No single-file entry point; configuration is per-platform.

Flutter desktop developers who need native platform integrations (especially macOS/Linux menu bar functionality) and Flutter framework maintainers exploring experimental desktop plugin patterns. Contributors should understand both Dart and native platform code (C++, Objective-C, Swift).

Explicitly experimental and early-stage. The README warns this is not officially supported and core desktop work has moved to the main Flutter repo. CI/CD is present (.github/workflows/ci.yml, lock.yaml), but the plugin directory structure suggests ongoing development rather than stable releases. Expect breaking changes and incomplete features.

High risk for production use: (1) explicitly labeled experimental by Google with no official support guarantee, (2) dual-platform native code (C++, Objective-C++, Swift) across three OS targets increases maintenance burden, (3) issue tracking directed away to flutter/flutter repo suggests split focus, (4) typical of early-stage plugins, breaking changes are expected between versions. Use only if you can tolerate instability or contribute fixes yourself.

Limited visibility from static file list. The repo structure shows an active menubar plugin with example apps for macOS and Linux. CI workflows (ci.yml, lock.yaml) indicate active testing. However, the redirect in README suggests development velocity may be lower than the main Flutter project. No recent commit dates visible in provided data.

Clone and navigate to the plugin of interest: git clone https://github.com/google/flutter-desktop-embedding.git && cd flutter-desktop-embedding/plugins/menubar/example. For macOS: open macos/Runner.xcworkspace then build in Xcode. For Linux: mkdir -p linux/build && cd linux/build && cmake .. && make && ../build/menubar_example. Requires Flutter SDK 3.0+ and platform-specific dev tools (Xcode, CMake).

Daily commands: Per-platform: macOS: cd plugins/menubar/example/macos && pod install && open Runner.xcworkspace then ⌘R in Xcode. Linux: cd plugins/menubar/example/linux && mkdir build && cd build && cmake .. && make && ./menubar_example. Dart/Flutter layer: flutter run from plugins/menubar/example after platform setup. No single universal run command; each platform is independent.

• plugins/README.md — Entry point for understanding the plugin ecosystem structure and how to use all plugins in this repository.
• plugins/menubar/lib/menubar.dart — Main public API for the menubar plugin, exposing the primary functionality that developers integrate with.
• plugins/menubar/lib/src/menu_channel.dart — Dart-side platform channel implementation that bridges Flutter UI code to native platform implementations.
• plugins/menubar/linux/CMakeLists.txt — Build configuration for Linux native implementation; critical for understanding cross-platform native compilation.
• plugins/menubar/example/lib/main.dart — Primary example application demonstrating how to use the menubar plugin in practice.
• CONTRIBUTING.md — Contributor guidelines that define development expectations and submission processes for all contributors.
• README.md — Project-level orientation explaining this repo's scope as experimental plugins and redirecting desktop embedding work to Flutter core.

• menubar.dart (Dart) — Exposes unified Dart API for setting application menus; re-exports core types
  • Failure mode: API breaking changes impact all consumers; missing type exports prevent compilation
• menu_channel.dart (Dart, MethodChannel) — Manages platform channel lifecycle and message serialization between Dart and native code
  • Failure mode: Serialization bugs cause method call failures; channel name mismatches break IPC
• Linux native implementation (C++, GTK3, CMake) — Implements GTK-based menu creation and management for Linux desktops
  • Failure mode: Segmentation faults or GTK errors crash the application; missing library dependencies break compilation
• macOS native implementation (Swift, Objective-C, Cocoa) — Implements Cocoa NSMenu creation and binding to application instance
  • Failure mode: Incorrect NSApp delegation causes menu not to display; Swift/Objective-C bridging issues cause runtime errors
• Windows native implementation (C++, Win32 API) — Implements Win32 menu APIs for window menu bar creation
  • Failure mode: Invalid menu handles cause menu operations to fail silently; HWND lifecycle issues cause memory leaks

• Developer Dart code → menubar.dart (public API) — Developer calls setApplicationMenu() with menu item tree structure
• menubar.dart → menu_channel.dart (MethodChannel) — Serializes menu item tree to JSON and invokes native 'setMenu' method
• menu_channel.dart → Native platform code (Linux/macOS/Windows) — MethodChannel routes method call to platform-specific native implementation
• Native platform code → Operating System menu APIs — Native code translates menu structure into platform-specific API calls (GTK, Cocoa, Win32)
• Operating System → User Interface — OS renders application menu bar in window title bar or application menu

Add a new menu item type

1. Define the new menu item model in the data class (plugins/menubar/lib/src/native_menu_item.dart)
2. Update the serialization/deserialization logic in menu_channel.dart to handle the new type (plugins/menubar/lib/src/menu_channel.dart)
3. Add handler for the new type in Linux native implementation (plugins/menubar/linux/include/menubar)
4. Update the example to demonstrate the new menu item (plugins/menubar/example/lib/main.dart)

Add support for a new platform

1. Create platform-specific directory (e.g., plugins/menubar/android) with CMakeLists.txt or equivalent build file (plugins/menubar/linux/CMakeLists.txt)
2. Implement method channel handlers in native code for platform-specific menu creation (plugins/menubar/lib/src/menu_channel.dart)
3. Create example app structure for the platform (plugins/menubar/example/linux)
4. Update pubspec.yaml to declare platform plugin support (plugins/menubar/pubspec.yaml)

Add integration tests for the plugin

1. Create test file in example integration_test directory following existing pattern (plugins/menubar/example/integration_test/plugin_integration_test.dart)
2. Add test methods that call the Dart plugin API and verify native behavior (plugins/menubar/lib/src/menu_channel.dart)
3. Configure CI workflow to run integration tests on all platforms (.github/workflows/ci.yml)

• Dart + MethodChannel — Standard Flutter IPC mechanism for cross-platform plugin development; allows single Dart API to reach multiple native implementations
• C++ with CMake — Linux implementation uses standard GTK/C++ pattern; CMake provides cross-platform build compatibility
• Swift + Objective-C — macOS native APIs require Cocoa/AppKit which are most directly accessible through Swift and Objective-C
• Win32 C++ — Windows native menu APIs are Win32; C++ provides direct access to Windows menu structures

• Plugins remain experimental and separate from Flutter core

  • Why: Allows rapid iteration on desktop-specific features without blocking Flutter releases
  • Consequence: Users must manage plugin dependencies separately; API may change between versions without Flutter core integration promises

• Single menubar plugin covering multiple platforms

  • Why: Unified Dart API reduces developer burden of learning platform-specific menu APIs
  • Consequence: Some platform-specific menu features may not be fully exposed; requires careful abstraction design

• Example apps included per-platform in the plugin repo

  • Why: Demonstrates correct integration patterns and serves as integration test harness
  • Consequence: Increases repo size and maintenance burden; each platform update requires testing across all examples

• This repository does not contain Flutter desktop embeddings; that work moved to Flutter core
• This is not an official Flutter project; plugins are experimental and unsupported
• Does not provide web or mobile plugin implementations; desktop-only scope

• undefined: undefined

Platform-specific toolchain versions: macOS requires Xcode + CocoaPods (Podfile in example), Linux requires CMake 3.10+ and C++ compiler; no version pinning visible in provided files, leading to potential build failures on mismatched toolchains. Split plugin structure: each platform is nearly independent—changes to Dart API must be manually mirrored in macos/.swift and linux/.cc; easy to miss. Issue routing: bugs should not be filed here but in flutter/flutter instead; reporting to wrong repo will be closed/redirected. No web support: this is desktop-only; trying to run on web will fail silently. Integration test discovery: plugins/menubar/example/integration_test/plugin_integration_test.dart follows specific naming to be picked up by CI; renaming breaks CI detection.

• Platform Channels (MethodChannel) — The core mechanism for Dart↔native communication in Flutter plugins; your plugin Dart code calls native C++/Swift via MethodChannel, essential to understand for any feature implementation
• CMake Build System — Linux build configuration in this repo uses CMake; you must understand CMakeLists.txt to modify native builds or add dependencies
• Objective-C++ (Objective-C and C++ hybrid) — macOS native code in this repo is written in Objective-C++; understanding the hybrid syntax is essential for macOS platform modifications
• Swift Interoperability with C++ — Some macOS code uses Swift instead of Objective-C++; understanding Swift-to-C++ bridging is needed for modern macOS implementations
• Pubspec Plugin Format — Flutter plugins declare platform-specific code via pubspec.yaml; understanding ffiLibrary, pluginClass, and platforms keys is required to structure plugin metadata correctly
• [Native Menu Integration (macOS NSMenu, Linux GtkApplication)](https://developer.apple.com/documentation/appkit/nsmenu and https://developer.gnome.org/gtk4/stable/) — The menubar plugin specifically integrates with platform menu systems; understanding NSMenu for macOS and GTK for Linux is required to extend menu functionality
• Xcode Project Configuration (pbxproj format) — macOS build config is stored in binary pbxproj; while usually edited via Xcode GUI, understanding native dependency linking and framework searches is needed for troubleshooting

• flutter/flutter — The main Flutter repo containing the officially supported desktop embedding; this experimental repo's work eventually feeds into here
• flutter/plugins — Official Flutter plugin ecosystem; shows stable patterns and standards that experimental plugins here are exploring
• google/flutter_template_images — Google-maintained Flutter resources; complementary templates for desktop app structure
• flutter/packages — Core ecosystem packages; some desktop utilities like platform_interface are dependencies of plugins in this repo
• windows-rs/windows-rs — Windows native API bindings for Rust; relevant for potential Windows implementation patterns in this desktop-focused repo

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for menubar plugin across Linux, macOS, and Windows

The menubar plugin has an example app with integration_test/ directory that only contains plugin_integration_test.dart, but there are no actual platform-specific integration tests. Given this is a desktop plugin repo supporting multiple platforms, comprehensive integration tests would validate menubar functionality across Linux (GTK), macOS (Cocoa), and Windows (Win32) platforms. This is critical for experimental plugins.

• [ ] Expand plugins/menubar/example/integration_test/plugin_integration_test.dart with actual test cases for menu creation, item addition, and callbacks
• [ ] Add platform-specific test fixtures in plugins/menubar/example/linux, plugins/menubar/example/macos (and Windows if exists)
• [ ] Create a GitHub Actions workflow step in .github/workflows/ci.yml to run integration_test on all three platforms
• [ ] Document test running instructions in plugins/menubar/README.md

Add CMake build verification for Linux plugin implementations

The menubar example has a CMakeLists.txt for Linux (plugins/menubar/example/linux/CMakeLists.txt), but the main plugin implementation directory structure is missing from the file list. Many desktop plugins have C++ implementations that need build validation. A GitHub Actions workflow should verify Linux builds don't regress across PRs.

• [ ] Create a new GitHub Actions workflow at .github/workflows/linux-build.yml that runs cmake builds for all plugins in the plugins/ directory
• [ ] Verify the workflow tests both Debug and Release configurations
• [ ] Document Linux build prerequisites in CONTRIBUTING.md (required packages, CMake version, etc.)
• [ ] Add badges to plugins/README.md showing build status

Create a plugin development template and checklist in CONTRIBUTING.md

CONTRIBUTING.md exists but appears incomplete based on the README note redirecting users elsewhere. With multiple experimental plugins and desktop platforms (Linux/macOS/Windows), new contributors need clear guidance on plugin structure requirements, file organization, and platform-specific implementation expectations.

• [ ] Document the expected directory structure (example/linux, example/macos, example/windows) in CONTRIBUTING.md
• [ ] Add a checklist of required files per platform (CMakeLists.txt for Linux, Podfile for macOS, etc.)
• [ ] Reference the menubar plugin structure as an example implementation in CONTRIBUTING.md
• [ ] Document required sections in plugin README.md files (description, platform support matrix, building instructions)
• [ ] Add guidance on testing requirements (unit, integration, platform-specific)

• Add platform-specific unit tests for Linux C++ menu bar rendering (plugins/menubar/linux/ currently has no *_test.cc files visible), mirroring the macOS test patterns. Requires basic C++ GoogleTest knowledge.
• Document the platform channel protocol between Dart and native code in plugins/menubar/README.md—currently no diagram or message format spec is visible. Would clarify extension points for contributors.
• Add missing example in plugins/menubar/example/lib/ showing how to dynamically add/remove menu items at runtime (only static example visible). Requires understanding both Dart and one native platform implementation.

The codebase shows reasonable basic security practices with version control configuration (.gitignore) and issue templates. However, critical information for comprehensive security analysis is missing: no dependency manifests were provided, preventing vulnerability scanning of third-party packages. The project is marked as experimental/early-stage, which implies ongoing development. Recommendations include providing complete dependency information for analysis, establishing a clear security policy, and documenting security considerations for plugin usage. No hardcoded secrets, SQL injection risks, XSS vulnerabilities, or critical misconfigurations were evident from the file structure analysis.

• Medium · Incomplete Dependency Information — Root level and plugin directories. No package dependency files (pubspec.yaml, package.json, etc.) were provided for analysis. This prevents evaluation of known vulnerabilities in third-party dependencies used by the Flutter plugins. Fix: Provide complete dependency manifests and regularly audit dependencies using tools like 'flutter pub outdated' and vulnerability scanners such as 'pub.dev security advisories'.
• Low · Generated Code Visibility — plugins/menubar/example/linux/flutter/, plugins/menubar/example/macos/, plugins/menubar/example/windows/flutter/. Generated plugin registrant files are committed to version control (generated_plugin_registrant.cc, generated_plugin_registrant.h, GeneratedPluginRegistrant.swift). While not inherently a vulnerability, generated code should typically be excluded from VCS. Fix: Add generated files to .gitignore or use build system to generate them at compile time. Review .gitignore configuration to ensure generated artifacts are properly excluded.
• Low · Missing Security Policy Documentation — Root directory. No SECURITY.md file found in the repository. While macOS-Security.md exists, there is no clear security policy or reporting mechanism for vulnerabilities. Fix: Create a SECURITY.md file outlining the security policy, vulnerability disclosure process, and supported versions for security updates.
• Low · Incomplete README Security Guidance — README.md, plugins/README.md. The README indicates this is an experimental/early-stage project with plugins. Security considerations specific to these plugins are not documented. Fix: Document security considerations for plugin usage, known limitations, and best practices for integrating these experimental plugins into applications.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.