feat: Allow toggling hosts directly from tray menu - #1052
Closed
sirbrillig wants to merge 3 commits into
Closed
sirbrillig wants to merge 3 commits into
sirbrillig wants to merge 3 commits into
Conversation
`apply_hosts_selection` mixed argument handling with the apply pipeline itself — the privileged write, the history journal, the `system_hosts_updated` broadcast, the tray title refresh and `cmd_after_hosts_apply`. Only the renderer could reach any of it. Extract everything after the argument check into `apply_content_to_system`, leaving the command as the thin shell that validates `args[0]` and delegates. No behaviour change: the helper returns the same JSON envelope the renderer has always received.
The tray menu could only open the main window, so switching a configuration always meant bringing up a window first. It now lists every hosts entry as a check item — folders become submenus, with the folder's own toggle at the top since a submenu parent isn't clickable. Clicking an item runs the whole pipeline in Rust rather than emitting `toggle_item` for the renderer the way `http_api::api_toggle` does. The menu bar is reachable in states where no renderer is: under `lightweight_mode` closing the main window destroys its webview, and `hide_at_launch` never creates one. A menu-bar toggle that did nothing in exactly the "app lives in the tray" setup it exists for would be useless. `hosts_toggle::set_on_state_of_item` ports `setOnStateOfItem` from `src/common/hostsFn.ts`, so `choice_mode`, per-folder `folder_mode` and `multi_chose_folder_switch_all` cascade the same from the menu as from the list. The apply reuses `apply_content_to_system`, so both paths journal history and broadcast identically. `manifest.json` is written only after a successful apply — a dismissed auth prompt leaves the stored selection alone — and the menu is rebuilt either way, since the OS flips a check item's mark on click and a cancelled apply would otherwise leave the menu claiming a state `/etc/hosts` doesn't have. Two guards match the renderer: no hosts items during data-directory recovery, and an unset `write_mode` opens the write-mode dialog instead of guessing between append and overwrite.
With a long list of configurations the tray menu gets unwieldy, so not everyone wants it carrying one. Advanced preferences gains "Switch Hosts from the Tray Menu", on by default so current behaviour is unchanged; turning it off leaves the menu exactly as it was before the hosts items existed. The check lives in `tray::hosts_nodes`, next to the data-directory recovery case that already returns an empty list, so one place decides whether the menu lists hosts entries at all. `apply_side_effects` now treats `show_hosts_in_tray_menu` like `locale` and rebuilds the menu when the preference flips, so it takes effect without a restart.
Author
|
Oh, I just noticed that this should be based on the |
Author
|
Moved to #1053 |
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.
Proposed changes
This PR adds per-entry toggles to the tray menu, so a hosts configuration can be switched straight from the menu bar without opening a window.
Clicking an item runs the apply pipeline natively in Rust rather than delegating to the renderer. I also added a preference that lets anyone turn off the list if they like.
Why are these changes being made?
Switching between host configurations is the main reason for this app but since version 5 that requires opening the main window which is a lot of extra clicks for something I need to do many times a day.
The interesting decision is doing the work in Rust instead of emitting
toggle_itemand letting the renderer's existingonToggleItemhandle it, which is whathttp_api::api_toggledoes. That would have been a much smaller change, but the menu bar is reachable in states where no renderer is: underlightweight_modeclosing the main window destroys its webview, andhide_at_launchnever creates one.Testing instructions
Automated:
New coverage: 10 Rust tests for the
setOnStateOfItemport (single/multi choice mode, folder cascading, parent roll-up), 3 for the menu id/label helpers, and an e2e test for the new preference. The port was also cross-checked against the TypeScript original by running both over the same 10 scenarios.Manual testing:
npm install && npm run tauri:dev/etc/hostsshould be updated and the main window's list, the tray title and the menu's check marks should all agree.Note for the maintainer
http_api::api_toggle(GET /api/toggle, used by the bundled Alfred workflow) still emitstoggle_itemfor the renderer to handle, so it is a silent no-op underlightweight_mode/hide_at_launch. The documentation at the top ofhttp_api.rsis not accurate. Now thathosts_toggle::toggle_itemexists it could be changed to be a few lines and work even if the window is closed.