Hi Tim Will `make reset-gaia` also clear the prefs in Gecko back to original settings? If it couldn't, how does Gecko know it should go to the 'Default' state instead of the previous state before rebooting? If it could, that will surpise me because it *resets* not only gaia but also some gecko bits.
Also the enabling/disabling states should be left to API implementation. For example, In NFC it has different power states, the state used in P2P sharing and in Card Emulation mode are different. Adding many 'ING' states, IMO, could make the API difficult to use. Thanks On Tue, Dec 30, 2014 at 3:42 PM, Tim Guan-tin Chien <[email protected]> wrote: > On Tue, Dec 30, 2014 at 1:34 PM, Tim Guan-tin Chien > <[email protected]> wrote: > > On Tue, Dec 30, 2014 at 12:44 PM, Hsin-Yi Tsai <[email protected]> > wrote: > >> Hi all, > >> > >> One more question: with this new proposal, how are applications going to > >> display "user preference" instead of a current state, like what we've > done > >> in utility tray? Need one more attribute? > >> > > > > Most of the time, interfaces are designed to be a both read and write > > interface for user (e.g. checkbox). > > I am not entirely sure what you mean by utility tray. The quick > > settings buttons exhibits the same behavior. > > > > If the user are allowed to change things and only apply when they say > > so, I would imaging such UI be placed in a dialog with Back/OK buttons > > (and with OK means apply now) > > Hi all, > > 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. > > Also, the switch state has no requirement to bind the hardware state > -- such as network state of the WIFI or RIL. It's up to the API or the > hardware to define the requirement to fulfill the hardware request > (e.g. the already connected network must be disconnect before we > fulfilled the hardware-disable request). The only requirement here is > section A point 1: to prevent race (to the hardware or the UI), we > should reject the API call when the state machine is "working" (i.e. > "enabling" or "disabling") or when the operation is simply invalid > (i.e. the state is already "disabled"). > > Thanks, > > Tim > _______________________________________________ > dev-webapi mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-webapi >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
