A menu bar / tray app for rig on Windows

[gaborcsardi]

Rig.app gives macOS users a menu bar item that shows the current default R version and switches it in one click. Windows has nothing equivalent. This is a write-up of what it would take, including the two things that do not translate cleanly.

The backend is already there

The macOS app is ~680 lines of Swift under Rig.app/Rig/, talking to the libriglib.a static library through 11 extern "C" functions in src/lib.rs. That file is gated #![cfg(target_os = "macos")] at line 1.

Every function behind that C API already has a Windows counterpart:

src/lib.rs C API	Windows implementation
rig_list, rig_list_with_versions	sc_get_list in src/windows/mod.rs
rig_get_default	sc_get_default in src/windows/mod.rs
rig_set_default	sc_set_default in src/windows/mod.rs
rig_r_root	get_r_root in src/windows/mod.rs
rig_start_rstudio	sc_rstudio_ in src/windows/mod.rs
rig_library_list, rig_lib_set_default	src/library.rs, already cross-platform
rig_mode	get_mode in src/utils.rs

So no new backend logic is needed, only a front end.

Suggested approach: a second Rust binary, no C API

On macOS the split into a static library plus a Swift app exists because the UI has to be Swift. On Windows there is no such constraint, so the C API is pure overhead. A tray app can just be another binary in the same crate that calls windows::sc_get_list() and friends directly — no FFI, no char* buffers, no second toolchain.

[[bin]]
name = "rig-tray"
path = "src/bin/tray.rs"

• Tray icon and menu: the tray-icon crate (from the Tauri project, wraps Shell_NotifyIcon), with tao or winit for the event loop.
• #![windows_subsystem = "windows"] so no console window appears.
• Watching for changes: the notify crate, which uses ReadDirectoryChangesW. This replaces DirectoryWatcher.swift (kqueue) and would watch get_r_root(), exactly like updateWatcher() does today.
• Preferences: reuse rig's own src/config.rs instead of the UserDefaults storage that RigPreferences.swift uses.

Roughly 400–600 lines of Rust and three new dependencies. Notably it needs no Xcode equivalent — everything builds with the existing cargo build on Windows.

Constraint 1: the Windows notification area has no text label

The macOS status item title is currently something like R 4.5.1 (mylib). There is no way to reproduce that on Windows, and it is not a Rust limitation.

Shell_NotifyIcon is the only supported systray API, and NOTIFYICONDATA has exactly two display fields: hIcon and szTip (the tooltip). There is no label field. The taskbar is rendered by explorer.exe, not by the application, so WinForms NotifyIcon, WPF, WinUI 3 and plain Win32 all wrap the same call and hit the same wall. NSStatusItem is different because it hands you a real NSButton that you own and draw into.

The historical escape hatches are gone:

• Deskbands (IDeskBand2) were the only supported way to put arbitrary text in the taskbar. Deprecated in Windows 10, non-functional in Windows 11.
• Taskbar toolbars were removed in Windows 11.
• The Windows 11 widgets board is a separate surface behind a click, not persistent chrome.

What does work: generating the icon at runtime. Draw the version into a bitmap and build the HICON on the fly rather than loading a static .ico, redrawing whenever the default changes. This is what CPU and battery monitors do. The budget is small — 16×16 logical, up to 32×32 at 200% DPI — so realistically two or three glyphs:

• 4.5 fits, either condensed or stacked on two lines
• 4.5.1 does not fit
• 4.5.1 (mylib) is nowhere close

So the proposal is: icon shows the abbreviated version, the tooltip carries the full R 4.5.1 (mylib) string, and the full version plus library name stay in the menu, where they are already listed. This can be done in Rust with GDI via the windows crate (CreateDIBSection, DrawText, CreateIconIndirect), or by drawing with tiny-skia/ab_glyph; tray-icon accepts an icon built from a raw RGBA buffer either way.

Also worth knowing: Windows 11 hides new tray icons in the overflow flyout by default, and the user has to drag one onto the taskbar to pin it. The installer or a first-run notice should probably mention this.

Constraint 2: elevation in admin mode

This is the bigger problem. sc_set_default in src/windows/mod.rs calls escalate("setting the default R version"). In admin mode it writes R.bat, RS.bat and Rscript.bat into C:\Program Files\R\bin and updates HKLM, so switching versions means a UAC prompt every single time the user picks a version from the tray menu. That defeats the purpose of a one-click switcher.

User mode has none of this: quick links go to %USERPROFILE%\.local\bin, registry writes go to HKCU, and escalate is a no-op.

Options:

1. Ship the tray app as a user-mode feature. If get_mode() returns Admin, show the menu disabled with a pointer to rig system user-mode. This seems like the right call — it is honest about the constraint and nudges toward the mode that actually works well here.
2. Run the tray app elevated at login via a scheduled task with highest privileges. It works, but any RStudio session launched from the menu inherits the elevated token, which is not great.
3. Accept a UAC prompt per switch. Not really viable.

Option 1 is the recommendation.

Packaging

rig.iss (Inno Setup) would need to install rig-tray.exe, add a Start Menu shortcut, and optionally register autostart under HKCU\Software\Microsoft\Windows\CurrentVersion\Run. An .ico is also needed — Resources/ currently only holds macOS assets.

Side benefit

Because tray-icon is cross-platform, the same code could eventually replace the Swift app on macOS and Linux and leave rig with a single UI codebase. The cost of doing that on macOS would be losing the text label in the menu bar, so it is probably not worth it there — but it is an option worth keeping in mind rather than a door this closes.