Add GSetting to disable aeroplane/airplane mode UI/behaviour while it has side effects even without active use
Per #613 (closed), aeroplane mode functionality currently interferes with other radio state even when none of the specifix aeroplane mode UI is used.
Specifically, turning on/off specific radios results in unrelated radio states being toggled, and/or their toggles becoming insensitive.
On #613 (closed), @bberg asked for a proposed solution that wouldn't cause UX regressions, and a GSetting to disable all aeroplane mode behaviour would meet this criterion.
@hadess closed #613 (closed) with the following:
No. If you don't want the feature to be used, just don't show any UI for it. This is the best we can implement given the kernel APIs available and the hardware it supports.
I would have replied there, but unfortunately he also locked that issue.
The above response does not seem to be an adequate reason to close that issue for the following reasons:
don't show any UI for it
I'm a user, not a developer of a downstream shell. This problem equally applies to GNOME Shell, not just Phosh (both use GNOME Settings/GSD). The linked Phosh issue was just an example because it's a case where there are many radios present, but it behaves exactly the same way on Shell under the same circumstances.
This is the best we can implement given the kernel APIs available
It's not clear why. All the radios can be toggled independently when not using GNOME Settings, which suggests that at a kernel level there is nothing blocking a better implementation.
The fundamental problem seems to be that "aeroplane mode" needs to be tracked by GSD separately from any radio state, and previous radio state when it's toggled also needs to be tracked, so they can be restored. There can always be some "expiry" conditions for previous radios state, e.g. if the device has been restarted, or any radios manually toggled elsewhere, then GSD doesn't try to restore from its remembered state when disabling aeroplane mode.
@hadess or others, I'd appreciate it if, in the case that this issue gets closed, you don't lock it, as that doesn't give the opportunity to respond to the given reason for closure, which in the case of #613 (closed) was at least part seemingly based on a misconception of the circumstances of the issue.