On Tue, Dec 30, 2014 at 7:56 PM, Tim Guan-tin Chien <[email protected]> wrote: > On Wed, Dec 31, 2014 at 10:47 AM, Jonas Sicking <[email protected]> wrote: >> On Mon, Dec 29, 2014 at 11:42 PM, Tim Guan-tin Chien >> <[email protected]> wrote: >>> I just talk to Hsin-Yi offline and I would like to make some >>> clarification here, by means of describing steps to run when the said >>> method is called: >>> >>> A. Steps to do when setFooEnabled(false) is called: >>> >>> 1. If the state is not "enabled", reject the promise and stop. >>> 2. If not, switch the property to "disabling". >>> 2. Dispatch a property change event. >>> 3. Submit the disable request to the relevant hardware. >>> 4. If the request is fulfilled by the hardware, >>> 4.1 Switch the property to "disabled". >>> 4.2 Set the persistent state to "disabled". >>> 4.3 Dispatch a property change event. >>> 4.4 Resolve the promise. >>> 5. If the request is rejected by the hardware, >>> 5.1 Switch the property back to "enabled". >>> 5.2 Dispatch a property change event. >>> 5.3 Reject the promise. >>> >>> B. Steps to do when the phone boots: >>> >>> 1. The state should start with "disabled". >>> 2. If the persistent state is "enabled", run steps as if >>> |setFooEnabled(true)| is called. >>> >>> The important thing to clarify is section A point 4.2: Persistent >>> state (e.g. Gecko pref) should not change if the request to hardware >>> is rejected -- therefore, a failed setFooEnabled() call should not >>> result any side effect. >> >> As a user, I'm not sure that this is the behavior that I want. >> >> The most simple scenario is if I turn off wifi, but the phone crashes >> before the wifi radio has been fully shut down, I think I'd prefer >> that the wifi was off after bootup. > > This can be solved if we write the pref to disk before calling the > hardware, and revert it if the hardware fail to fulfill the request. > The behavior can be kept internally to API implementations. > >> A slightly more complex scenario is if I turn on wifi, but for some >> reason wifi fails to turn on, do I really want the phone to give up >> rather than try again? Especially after a reboot which might actually >> fix some broken state in the wifi driver? This scenario is a more >> complex though since I don't know under what circumstances wifi would >> actually fail to turn on? > > This proposal is deliberately flawed to work with broken hardware. > Instead of quietly trying to call the hardware for the user (before > and after the reboot), the proposal is trying to be explicit to user > when hardware fail to fulfill the request(s). > >> One possible solution is to separate "desired state" from "hardware >> state". So when setFooEnabled(true) is called, we'd immediately save >> the new value in prefs, and then reflect "enabled" in a "desired >> state" property. But the "hardware state" property would behave as you >> describe above and would switch to "enabling". If turning the hardware >> on fails, the "hardware state" would switch back to "disabled". >> However the "desired state" would still reflect "enabled". The API >> could then retry to turn on the hardware if that's appropriate. >> >> If we did this we could technically still use mozSettings to track the >> "desired state", and the individual API to track the "hardware state". >> But that might just make for a more complex API. But might mean >> smaller changes compared to what we have now. >> > > The proposal is designed such that "desired state" and "hardware > state" is kept in sync as closely as possible, streamlining the > interfaces between three. What you are describing is what we are doing > right now -- keeping the desired state in mozSettings and have the API > to track the changes and try to achieve the described hardware state.
I guess what I'm saying is that I'm not convinced that this makes for a good UX. I know that it's quite annoying when I accidentally turn on or off some piece of hardware, and have to wait a few seconds before I can "undo" it. I'd rather be able to flick the switch as much as I want, and have a status indicator next to the switch indicating if the hardware is currently on/off/switching. But if the complexity to make that work is really too hard, then I agree that we might have more important things to work on. > It's proven to be complex for both Gecko and Gaia, when the user > attempt to toggle many times in a short interval -- something fairly > common being tried by QA forks. > > I) For Gecko, since there is no way to deny changes in desired state, > it would always have to "catch up" with the changes, presumably by > queue the state change and send the requests to hardware one-by-one. > II) For Gaia, we would have hard time to find the right timing for > disabling/re-enabling the UI (to express the "working" state and > provide a "cool down" period). Oh, and doing that on all toggles of > the same setting on different apps. > >> I do agree that this is a more complex system though. And one that >> requires UI authors to deal with more state and more complexity. >> > > Exactly. > > There is one even simpler alternative: We drop the UI requirement of > (II) and ensure every Gecko API have (I) properly implemented. But > then we will get bugs like "I am able to toggle 'airplane mode' 5 > times in 1 sec but the icon only shows up after 1 minute." and we > would have to argue that it's not a bug :) We don't really have to queue up all changes. I.e. if the user switches airplane mode on/off 5 times while gecko is still in the process of turning airplane mode on for the first time, we don't need to turn it on/off 4 more times. We'll just check the current state compared to the desired state, and if they are not in sync change one more time. / Jonas >> So I'm happy to go with what you are proposing if people think that >> makes everyone's life simpler. >> >> / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
