GNOME Bugzilla – Bug 761051
Overhaul flight mode - align to end user expectations
Last modified: 2019-03-20 11:32:45 UTC
The flight of gnome shell works totally different compared to what users are used from other (mobile) systems like android. On android flight mode is a mode that you manually enable (or via a trigger), but it is not automatically enable if the phone is a state similar to flight mode. DISABLING WIRELESS: Android: When you disable all wireless functions (wifi, bluetooth) but do not enable flight mode then flight mode stays disabled. Gnome shell: When you disable wifi and bluetooth the system enabled flight mode for you, without asking. ENABLING FLIGHT MODE: Android: If you wifi is on and you bluetooth is on, and you enable and then disable flight mode android will restore the wireless devices to the same state as before. So wifi is enabled, and bluetooth stays disabled (in this example). Gnome Shell: If your wifi is on and bluetooth is off and you enable and then disable flight mode, then the system will enable both of these devices (if you only have these). The user then needs to do at least 3 steps to restore the old state. I like that gnome has a flight mode. But it behaves totally different than i (and some other users i asked) expected. I think it would be more intuitive if the flight mode would behave the same as on other systems.
Airplane mode is actually implemented in gnome-settings-daemon, all we do in the shell is showing or hiding the icon (and ask gnome-settings-daemon to turn airplane mode off when the user selects the corresponding menu item), so reassigning.
Moving to rfkill component.
*** Bug 764390 has been marked as a duplicate of this bug. ***
I think this basically boils down to having a "virtual" Airplane mode state (which cannot be enabled by disabling all devices). If the user enabled Airplane mode we store the list of devices which were switched to the off state. Then, when disabling Airplane mode these are re-enabled. Ideally the following holds true: * Enabling Airplane mode disables all active devices (and stores them) * Disabling Airplane mode re-enables these devices (this can be *no* device if all devices were off to begin with) * Enabling Wifi and Bluetooth while in Airplane mode is allowed * Enabling a modem while in Airplane mode is impossible * Airplane mode is never enabled implicitly (i.e. disabling all devices will not enable airplane mode, and you may have airplane mode on with an empty list of devices that should be re-enabled) * Devices that appear should get the expected state for the device type I am not sure about: * Whether we have a separate modem switch or not. However, I think this does not fundamentally affect the general logic. * Whether Airplane mode should be disabled when all devices are turned on. I am thinking that this should be the case.
Apart from the modem question this is exactly what i expected from the feature in the first place. Very good description.
(In reply to Benjamin Berg from comment #4) > I think … This sounds very good to me! > * Airplane mode is never enabled implicitly > (i.e. disabling all devices will not enable airplane mode, and you may > have airplane mode on with an empty list of devices that should be > re-enabled) I disagree: If the airplane mode switch == modem switch (see below), then disabling the last modem should automatically enter airplane mode. > I am not sure about: > * Whether we have a separate modem switch or not. However, I think this does > not fundamentally affect the general logic. So you mean whether "Airplane switch" == "modem switch"? That would be ok for me, because "modem" is hard to explain sometimes… > * Whether Airplane mode should be disabled when all devices are turned on. > I am thinking that this should be the case. Maybe trying to enable modem while in airplane mode should warn and ask for confirmation.
(In reply to Benjamin Berg from comment #4) > I think this basically boils down to having a "virtual" Airplane mode state > (which cannot be enabled by disabling all devices). If the user enabled > Airplane mode we store the list of devices which were switched to the off > state. Then, when disabling Airplane mode these are re-enabled. There's no "airplane" state in the kernel either, and it causes all sorts of trouble: - when there's no Bluetooth adapter (we have no way to know whether there would be one or not in the machine before trying to enable it) - when the user expects that disabling the airplane mode will restore the "pre airplane mode" state, eg. a modem or Wi-Fi card that was disabled is still disabled
(In reply to Christian Stadelmann from comment #6) > > I am not sure about: > > * Whether we have a separate modem switch or not. However, I think this does > > not fundamentally affect the general logic. > > So you mean whether "Airplane switch" == "modem switch"? That would be ok > for me, because "modem" is hard to explain sometimes… > [SNIP] > Maybe trying to enable modem while in airplane mode should warn and ask for > confirmation. I don't think it should be possible to enable a modem while in airplane mode (I have *not* done the research but my assumption is that this is a regulatory requirement). I can see this either working by not a separate modem switch (i.e. airplane mode == modem switch) or to disallow turning the modem On without also turning airplane mode Off. Yes, a confirmation dialog is one way of solving this. (In reply to Bastien Nocera from comment #7) > - when there's no Bluetooth adapter (we have no way to know whether there > would be one or not in the machine before trying to enable it) Are there cases where we have a "bluetooth" rfkill switch but no bluetooth hardware exists? Then again, I don't think we can get better than to trust the presence of an rfkill switch to mean that bluetooth is available. > - when the user expects that disabling the airplane mode will restore the > "pre airplane mode" state, eg. a modem or Wi-Fi card that was disabled is > still disabled Yes. As I understand it, the whole point of this bug is that exactly that should happen.
*** Bug 787281 has been marked as a duplicate of this bug. ***
(In reply to Benjamin Berg from comment #8) > (In reply to Christian Stadelmann from comment #6) > > > I am not sure about: > > > * Whether we have a separate modem switch or not. However, I think this does > > > not fundamentally affect the general logic. > > > > So you mean whether "Airplane switch" == "modem switch"? That would be ok > > for me, because "modem" is hard to explain sometimes… > > [SNIP] > > Maybe trying to enable modem while in airplane mode should warn and ask for > > confirmation. > > I don't think it should be possible to enable a modem while in airplane mode > (I have *not* done the research but my assumption is that this is a > regulatory requirement). I can see this either working by not a separate > modem switch (i.e. airplane mode == modem switch) or to disallow turning the > modem On without also turning airplane mode Off. Yes, a confirmation dialog > is one way of solving this. Phones don't have a separate toggle for their baseband radio's rfkill. The airplane mode toggle acts as "all the killswitches" when you turned it on (so everything off), and you can then enable wifi and Bluetooth individually. I don't see a confirmation dialogue as being needed, unless you expect users to click that toggle inadvertently. > (In reply to Bastien Nocera from comment #7) > > - when there's no Bluetooth adapter (we have no way to know whether there > > would be one or not in the machine before trying to enable it) > > Are there cases where we have a "bluetooth" rfkill switch but no bluetooth > hardware exists? Then again, I don't think we can get better than to trust > the presence of an rfkill switch to mean that bluetooth is available. Yes. I remember Sony Vaio laptops being like that. I even wrote a hack to detect the Bluetooth adapter on boot, so that the rfkill presence and state would be "correct". It wasn't accepted. Mind, I haven't seen this in a number of years, but I guess that it's still a possibility on laptops where the Wi-Fi/Bluetooth cards are removable. > > - when the user expects that disabling the airplane mode will restore the > > "pre airplane mode" state, eg. a modem or Wi-Fi card that was disabled is > > still disabled > > Yes. As I understand it, the whole point of this bug is that exactly that > should happen.
*** Bug 794467 has been marked as a duplicate of this bug. ***
*** Bug 787800 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/288.