Should we have separate Host and Application settings?

[jandubois]

I was putting things that affect host integration into host (i.e. WSL integrations, the sudo stuff for docker socket integration, shell integration). I left the stuff that doesn't affect other applications on the host (telemetry, logging, updater) under application.

The current application page (on Windows) contains updates & telemetry, so I would definitely not advocate for renaming that; if anything, we might rename "WSL" to "Integration" and move sudo/environment there? But I'm not really advocating for UI changes here though :)

Originally posted by @mook-as in #3740 (comment)

If we want to have separate "Host" and "Application" pages in the Preferences in the future (and move the WSL page into a Home tab), then I would be willing to change the structure layout already, and modify the UI later.

If we are not planning to change the Preference tabs, then I would want to keep the settings under the existing page names.

Originally posted by @jandubois in #3740 (reply in thread)

[rak-phillip]

A proposed schema that reflects these changes would make it easier to envision how existing preferences remap in the UI.

I'd like to understand how differentiating between host and application preferences is a distinction that improves the UI. Is it critical for me to know as a user that administrativeAccess (sudo stuff) is a host preference vs. an application preference? I'm only interested in ensuring Rancher Desktop behaves as expected at the end of the day.

Not to say that I'm against the idea. I'm simply trying to get a complete idea of how this improves our preferences UI.

[jandubois]

I tried to sort app/host settings (mostly from #1924) into the Application and Host groups:

• Application
  • light/dark/auto mode
  • Accent/highlight colour
  • Hide icon in menu bar / notification area
  • Update settings
  • Statistics/Telemetry
• Host
  • PATH settings
  • enable shell completion
  • env variables for nerdctl
  • kubeconfig location
  • autostart at login; run in background
  • admin access
  • set kube context to rancher-desktop when the app is started

I find it not always clear which group a setting should go to.

For example I consider these settings as related:

1. auto-start at login
2. start app in background (without a window)
3. quit app when window is closed
4. hide icon in menu bar

So 1 is clearly a Host setting, and 3 is clearly an Application setting, but 2 and 4 I can't really tell for sure.

Anyways, splitting these settings not just across different tabs, but also different pages feels wrong to me, so right now I feel like rejecting the idea of splitting out Host from Application settings.

[jandubois]

I think 2 is probably an Application setting, and 4 is a Host setting, but I can't come up with clear criteria to draw the boundary.

[mook-as]

I think with the cases being from a user point of view, splitting those out to a separate page would probably not be great user experience. As such, if we want to tie the settings schema to the UI, that would probably not be a great thing to do.

I do suspect though that tying might become an issue, in the sense that sometimes we change our UI around. Though I guess in that case we can migrate the settings around anyway (because we still don't promise a stable API around the settings).

[jandubois]

I do suspect though that tying might become an issue, in the sense that sometimes we change our UI around.

Indeed, and that is (one) reason we don't group the settings by tab, i.e. there will be application.pathSetting but not application.environment.pathSetting. So we can move settings around between different tabs on the Application page, without the names becoming incorrect.

Another reason is of course that --application.environment.path-setting is really getting quite long...

Anyways, it sounds like we have agreement to not split Application/Host settings, so I will try to finalize the schema changes for v5. I may still ask for feedback on renaming individual fields, after cross-checking with the labels in the UI.