Fix taskbar/Activities generic icon on Linux (Console, Map, Mission Editor) / fixes #1667

[asikarastallion]

Summary

Fixes the generic "gear" taskbar/Activities icon reported in #1667. There were two independent root causes:

1. Mission Editor never set a window icon at all. MissionEditorFrame (MAVProxy/modules/mavproxy_misseditor/missionEditorFrame.py) never called SetIcon(), unlike ConsoleFrame and the Map window, which both call icon.SimpleIcon(...).get_ico(). Added a "WP" icon variant (numbered waypoint route) to MAVProxy/modules/lib/icon.py and set it on MissionEditorFrame, mirroring the existing Console/Map pattern.

2. GNOME/GTK3 doesn't use the runtime icon for the taskbar/Activities view at all. This is a documented GTK3/GNOME behavior, not a MAVProxy bug: the taskbar icon for a running window comes from an installed .desktop file whose StartupWMClass matches the window's WM_CLASS, not from wx.Frame.SetIcon() at runtime — see wxWidgets/wxWidgets#24034. MAVProxy shipped shortcuts/mavproxy.desktop, but nothing installed it (not even pip install), and it had no StartupWMClass, so GNOME never matched it to the running window and fell back to a generic icon.

Changes

• MAVProxy/modules/lib/icon.py: add a "WP" icon (dashed route with numbered waypoint markers) to SimpleIcon.
• MAVProxy/modules/mavproxy_misseditor/missionEditorFrame.py: call self.SetIcon(icon.SimpleIcon("WP").get_ico()) right after wx.Frame.__init__(), wrapped in the same try/except pattern wxconsole_ui.py already uses.
• shortcuts/mavproxy.desktop: add StartupWMClass=mavproxy.py, matching the actual WM_CLASS MAVProxy's windows report (confirmed via xprop WM_CLASS against live Console/Map windows).
• MAVProxy/tools/install_desktop_icons.py: new opt-in helper (python3 -m MAVProxy.tools.install_desktop_icons) that copies the .desktop files to ~/.local/share/applications and the icons to ~/.local/share/icons/hicolor/256x256/apps (the standard freedesktop icon theme location — the old ~/.icon path documented in the README is not searched by GTK), then best-effort refreshes the desktop/icon caches. Not run automatically by pip install, since pip can't reliably write to XDG user directories (especially into a venv, as in the original report).
• shortcuts/ReadMe.md: corrected install instructions, points at the new script, and notes that GNOME Shell may need a restart (Alt+F2 → r on X11, log out/in on Wayland) to pick up a newly-installed .desktop file for icon caches.

Root cause verification

• xprop WM_CLASS against running Console and Map windows: both report WM_CLASS(STRING) = "mavproxy.py", "Mavproxy" — confirming the value now set as StartupWMClass.
• xprop ... _NET_WM_ICON on a Mission Editor window created via the patched MissionEditorFrame shows a correctly-set 128×128 icon (previously absent entirely).
• Tested on Ubuntu 24.04 / GNOME (X11 session): before the fix, Console and Map showed the generic gear icon in Alt-Tab; after running the installer script and restarting GNOME Shell, both showed the correct MAVProxy icon.

Note on Mission Editor GUI verification

While testing, I found that under MAVProxy's normal module load misseditor / wp editor flow, the Mission Editor's window sometimes never appears at all — the child process (spawned via multiprocessing.Process, i.e. fork()) hangs indefinitely with zero output, even before its first line executes. This reproduces with or without this PR's changes (confirmed against the unmodified upstream code too), and matches the classic "fork() after a multi-threaded process has initialized GTK/holds a stdio lock" deadlock hazard — Console and Map run in the main process and are unaffected, but Mission Editor is deliberately forked into a child process (a workaround for an old macOS-specific wx issue, per the existing code comment). This is not something this PR touches or fixes; I did not modify mission_editor.py. I verified the SetIcon() fix itself works correctly by instantiating MissionEditorFrame directly in an unforked process (matching exactly how child_task constructs it), which reliably shows the window with the icon set. I'll file a separate issue for the forking hang since it's a pre-existing, unrelated bug.

AI assistance disclosure: This contribution was developed with the assistance of Claude (Anthropic) — both the conversational assistant and Claude Code. Claude helped investigate the root cause, draft the code changes, and prepare this PR description; I reviewed the diff, understand the change, and personally verified the testing results described above on my own machine.

Fixes #1667

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[tridge]

Automated review note — AI-generated (Claude), validated against the live diff. Please sanity-check before acting.
Full report: https://uav.tridgell.net/DevCallReviews/2026_09_01_AIReview/devcall_pr_reviews.html#prMAVProxy-1710

Reviewed at head 6dc1e356a1. REQUEST CHANGES — but the icon work itself is right; this is about packaging.

Good news first, because it's the part most likely to be silently wrong and it isn't: StartupWMClass=mavproxy.py is correct. Probing a real wxPython/GTK3 window from a script named mavproxy.py gives WM_CLASS(STRING) = "mavproxy.py", "Mavproxy", and gnome-shell matches StartupWMClass against res_class then res_name, so it hits on the instance name. The icon.py and missionEditorFrame.py changes also follow the existing project pattern exactly.

The blocker: the command your ReadMe tells users to run doesn't exist in a pip install. setup.py's packages=[...] doesn't list MAVProxy.tools, and no package_data glob covers tools/*.py. I built and installed this head into a clean venv: site-packages/MAVProxy/tools/ contains only graphs/, and import MAVProxy.tools.install_desktop_icons raises ModuleNotFoundError. It works only from a git checkout, which isn't who the ReadMe addresses.

And even if it were importable, shortcuts/ isn't shipped either. SHORTCUTS_DIR resolves three dirnames up from MAVProxy/tools/ — the repo root — which under a pip install is site-packages/shortcuts. There's no MANIFEST.in at this head and shortcuts/ sits outside the MAVProxy package, so no .desktop or .png is installed anywhere in the venv. The script degrades quietly ("shortcuts directory not found") rather than erroring, so the feature is simply inert for pip users.

The fix is small: move shortcuts/ under the package (e.g. MAVProxy/data/shortcuts/), add it to package_data, add MAVProxy.tools to packages, and resolve SHORTCUTS_DIR relative to the package rather than the repo root.

Two things that affect what this actually achieves. The Mission Editor icon won't appear in the GNOME taskbar regardless: console, map and mission editor all run as multiprocessing.Process children forked from mavproxy.py, and I probed a forked child's window — identical WM_CLASS — so GNOME groups them all under mavproxy.desktop and paints Icon=mavproxy. The per-window SetIcon still shows where _NET_WM_ICON is used, so the change isn't wrong; it just doesn't do what the title implies for that window. And mavexplorer.desktop/mavpicviewer.desktop didn't get a StartupWMClass line, so the claim about MAVExplorer is only half-delivered. It's also possible the real fix for #1667 is your ReadMe correction from ~/.icon to ~/.local/share/icons/hicolor/256x256/apps, since res_class Mavproxy already lowercases onto mavproxy.desktop via GNOME's existing fallback.

Worth knowing: no CI ran on this PR at all. check-runs for the head is total_count: 0, while sibling PRs have 2. Both workflows trigger on bare [push, pull_request] with no path filters, so it isn't path filtering — they were never approved for the fork branch. Running flake8 locally against the head passes, though note run_flake8.py only checks files carrying an AP_FLAKE8_CLEAN marker and the new files have none.

Minor: the installer hardcodes ~/.local/share rather than honouring $XDG_DATA_HOME; it has no platform guard, so running it on Windows would scatter files; mavpicviewer.png is 245×256 but installed into the 256x256 directory; and the new top-level import makes the mission editor a hard consumer of matplotlib, which it wasn't before.