#556: [retry] #448-I: GTK app shows generic taskbar/dock icon instead of the VimCode icon - #665
Merged
JDonaghy merged 2 commits intoAug 26, 2026
Conversation
…unner The quadraui GTK shell runner builds its `gtk4::Application` with a hard-coded `org.quadraui.app` id and exposes no override (see `quadraui::gtk::run`'s "Window title + app id" doc — "A future stage may add a builder API"). Since #540 flipped the GTK main loop from Relm4 to that runner, vimcode inherited the generic id, so the desktop environment could no longer resolve the installed `com.vimcode.VimCode.desktop` launcher for the live toplevel — and fell back to a generic gear icon. Fix it at the process level, where both live GDK backends actually read the toplevel's identity from, so nothing new is needed from quadraui: * Wayland — `xdg_toplevel.set_app_id` is fed from `g_get_prgname()`. * X11 — `WM_CLASS`'s instance name is `g_get_prgname()`, class derived. `apply_app_identity()` stamps `prgname` = `com.vimcode.VimCode` and `application_name` = `VimCode`, plus `gtk_window_set_default_icon_name` for WMs that read `_NET_WM_ICON` pixel data instead of matching a launcher. It is called from `run()` right after `gtk4::init()` and re-asserted from `ShellApp::setup`, which the runner invokes before `window.present()` — the last hook ahead of toplevel realization. Both GLib setters are write-once (a second `g_set_application_name` logs a warning), so the function no-ops when the value is already ours. `capture_window_and_apply_csd` additionally sets the per-window `icon-name` property once the runner's window is found. The app-id / icon-name / launcher-filename triple is now three constants (`APP_ID`, `APP_NAME`, `ICON_NAME`) shared by `install_icon_and_desktop` and the runtime identity, so they cannot drift apart — that drift is exactly what breaks icon matching. The `.desktop` body moves into a pure `desktop_entry()` so `Icon=` and `StartupWMClass=` are assertable without touching the user's $HOME. Tests (src/gtk/util.rs): launcher declares the matching WM class and the icon name that is actually installed into hicolor; `apply_app_identity` stamps prgname/application_name, is idempotent, and does not panic when GTK was never initialized (the headless harness, #646). Note for the coordinator: the clean long-term fix is a quadraui `ShellConfig::with_app_id()` / `with_icon_name()` builder so the runner creates its `Application` with the consumer's id. Worth filing on JDonaghy/quadraui; this change needs no quadraui edit in the meantime.
Reverts 59b5702. Review on issue #556 (fix iteration 1) found the prior commit violates CLAUDE.md's MANDATORY Platform-Neutrality Rule: it added ~80 lines of new GTK-specific logic (apply_app_identity, desktop_entry, three new constants, process-level glib::set_prgname/set_application_name surgery) to src/gtk/util.rs to work around a documented quadraui gap, instead of stopping and building the infrastructure upstream first. Verified the gap and the escape hatch quadraui offers today: quadraui::gtk::run's doc comment (quadraui/src/gtk/run.rs, "Window title + app id" section) says apps needing a custom app id must "build the runner via lower-level pieces in quadraui::gtk::backend / events" — i.e. reimplement `run()`/`activate()` (Application + window + DrawingArea + every event controller) themselves. That is not "thin event-to-engine wiring" under the Platform-Neutrality Rule either; it would be a much larger duplication of quadraui-owned GTK plumbing than the reverted patch. `ShellConfig` (quadraui/src/shell.rs) has no app_id/icon_name fields, confirming a builder API genuinely doesn't exist yet, exactly as quadraui::gtk::run's doc says ("A future stage may add a builder API"). Per the rule, the correct sequence is: file a quadraui issue for a `ShellConfig::with_app_id()` / `with_icon_name()` builder (or equivalent `quadraui::gtk::run` override), let that land upstream, then wire it into vimcode in 1-3 lines. That issue has not been filed yet — filing it is a coordinator action (workers on this repo don't run gh commands). Until it lands, vimcode's taskbar/dock icon under the ShellApp runner remains the generic gear icon (the original #448-I / #556 symptom); this revert intentionally does not re-fix that, only removes the non-compliant workaround so the codebase stays rule-compliant while the upstream infra is built. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #556
Automated PR opened by coordinator for review of issue #556.