----- Original Message -----
> From: "Tim Guan-tin Chien" <timdr...@mozilla.com>
> To: dev-g...@lists.mozilla.org
> Cc: "Eric Chou" <ec...@mozilla.com>, "Fabien Cazenave" <k...@mozilla.com>, "Kyle Machulis" <kmachu...@mozilla.com>
> Sent: Wednesday, July 11, 2012 2:31:29 PM
> Subject: [b2g] (mozBluetooth|mozWifiManager).setEnabled() and mozSettings
> (bcc dev-b2g@, please concentrate the discussion to dev-gaia@)
> Dear all,
> As I worked on Status Bar and Quick Settings, I found that turning
> on/off WIFI and Bluetooth is not done by mozSettings, but a
> setEnabled()
> method. That comes with some side effects:
> - the value doesn't stick after reboot
> - if Settings app and System are toggling the values on their own,
> they
> would have trouble sync the value and their UI.
> So I propose the following solution, if we all agreed, then code in
> Gaia
> should follow this flow:
> 1) We will create setting keys "bluetooth.enabled" and "wifi.enabled"
> that does nothing to platform but allow us to stick the value after
> reboot and sync the value across the apps.
> 2) App and the Status Bar should update the UI accordingly and they
> are
> NOT ALLOW to call setEnabled() method directly.
> 3) We will create bluetooth.js and wifi.js in the System app to match
> the value to actual setEnabled() method and do other stuff if it
> seems
> reasonable to do in System app.
> Using mozSettings value as a mean of cross-domain communication is
> not
> elegant, yet I believe with the current situation this is the only
> way.
> Kaze, would that be a problem for you? How soon do you think you can
> apply the Settings app with these rules?
> --
> Tim Guan-tin Chien, Front-end Dev, Mozilla Corp. (Taipei)
Gene will be working on the bug to allow wifiManager to consume mozSettings value directly. In the mean time, Evelyn will deliver a Gaia change that (A) actually ask Settings app and Quick Settings in System app to respect the mozSetting value, and (B) sync that value from mozSettings to wifiManager in System app.
The part (B) will be removed once Gene's platform fix is delivered.
Kaze, Evelyn is working on wifi part of the Settings app extensively, so you might need to hands off from there now.
> ----- Original Message -----
>> From: "Tim Guan-tin Chien" <timdr...@mozilla.com>
>> To: dev-g...@lists.mozilla.org
>> Cc: "Eric Chou" <ec...@mozilla.com>, "Fabien Cazenave" <k...@mozilla.com>, "Kyle Machulis" <kmachu...@mozilla.com>
>> Sent: Wednesday, July 11, 2012 2:31:29 PM
>> Subject: [b2g] (mozBluetooth|mozWifiManager).setEnabled() and mozSettings
>> (bcc dev-b2g@, please concentrate the discussion to dev-gaia@)
>> Dear all,
>> As I worked on Status Bar and Quick Settings, I found that turning
>> on/off WIFI and Bluetooth is not done by mozSettings, but a
>> setEnabled()
>> method. That comes with some side effects:
>> - the value doesn't stick after reboot
>> - if Settings app and System are toggling the values on their own,
>> they
>> would have trouble sync the value and their UI.
>> So I propose the following solution, if we all agreed, then code in
>> Gaia
>> should follow this flow:
>> 1) We will create setting keys "bluetooth.enabled" and "wifi.enabled"
>> that does nothing to platform but allow us to stick the value after
>> reboot and sync the value across the apps.
>> 2) App and the Status Bar should update the UI accordingly and they
>> are
>> NOT ALLOW to call setEnabled() method directly.
>> 3) We will create bluetooth.js and wifi.js in the System app to match
>> the value to actual setEnabled() method and do other stuff if it
>> seems
>> reasonable to do in System app.
>> Using mozSettings value as a mean of cross-domain communication is
>> not
>> elegant, yet I believe with the current situation this is the only
>> way.
>> Kaze, would that be a problem for you? How soon do you think you can
>> apply the Settings app with these rules?
>> --
>> Tim Guan-tin Chien, Front-end Dev, Mozilla Corp. (Taipei)
> Gene will be working on the bug to allow wifiManager to consume
> mozSettings value directly. In the mean time, Evelyn will deliver a
> Gaia change that (A) actually ask Settings app and Quick Settings in
> System app to respect the mozSetting value, and (B) sync that value
> from mozSettings to wifiManager in System app.
> The part (B) will be removed once Gene's platform fix is delivered.
> Kaze, Evelyn is working on wifi part of the Settings app extensively,
> so you might need to hands off from there now.
> Tim
> On Thu Jul 19 17:03:27 2012, Gene Lian wrote:
>> Tim,
>>> (bcc dev-b2g@, please concentrate the discussion to dev-gaia@)
>>> Dear all,
>>> As I worked on Status Bar and Quick Settings, I found that turning
>>> on/off WIFI and Bluetooth is not done by mozSettings, but a
>>> setEnabled()
>>> method. That comes with some side effects:
>>> - the value doesn't stick after reboot
>>> - if Settings app and System are toggling the values on their own,
>>> they
>>> would have trouble sync the value and their UI.
>>> So I propose the following solution, if we all agreed, then code in
>>> Gaia
>>> should follow this flow:
>>> 1) We will create setting keys "bluetooth.enabled" and "wifi.enabled"
>>> that does nothing to platform but allow us to stick the value after
>>> reboot and sync the value across the apps.
>>> 2) App and the Status Bar should update the UI accordingly and they
>>> are
>>> NOT ALLOW to call setEnabled() method directly.
>>> 3) We will create bluetooth.js and wifi.js in the System app to match
>>> the value to actual setEnabled() method and do other stuff if it
>>> seems
>>> reasonable to do in System app.
>>> Using mozSettings value as a mean of cross-domain communication is
>>> not
>>> elegant, yet I believe with the current situation this is the only
>>> way.
>>> Kaze, would that be a problem for you? How soon do you think you can
>>> apply the Settings app with these rules?
>>> --
>>> Tim Guan-tin Chien, Front-end Dev, Mozilla Corp. (Taipei)
On Thu Jul 19 17:49:45 2012, Tim Guan-tin Chien wrote:
> Gene, Kaze, Evelyn,
> We just have a offline discussion about this.
> Gene will be working on the bug to allow wifiManager to consume
> mozSettings value directly. In the mean time, Evelyn will deliver a
> Gaia change that (A) actually ask Settings app and Quick Settings in
> System app to respect the mozSetting value, and (B) sync that value
> from mozSettings to wifiManager in System app.
> The part (B) will be removed once Gene's platform fix is delivered.
> Kaze, Evelyn is working on wifi part of the Settings app extensively,
> so you might need to hands off from there now.
> Tim
> On Thu Jul 19 17:03:27 2012, Gene Lian wrote:
>> Tim,
>>> (bcc dev-b2g@, please concentrate the discussion to dev-gaia@)
>>> Dear all,
>>> As I worked on Status Bar and Quick Settings, I found that turning
>>> on/off WIFI and Bluetooth is not done by mozSettings, but a
>>> setEnabled()
>>> method. That comes with some side effects:
>>> - the value doesn't stick after reboot
>>> - if Settings app and System are toggling the values on their own,
>>> they
>>> would have trouble sync the value and their UI.
>>> So I propose the following solution, if we all agreed, then code in
>>> Gaia
>>> should follow this flow:
>>> 1) We will create setting keys "bluetooth.enabled" and "wifi.enabled"
>>> that does nothing to platform but allow us to stick the value after
>>> reboot and sync the value across the apps.
>>> 2) App and the Status Bar should update the UI accordingly and they
>>> are
>>> NOT ALLOW to call setEnabled() method directly.
>>> 3) We will create bluetooth.js and wifi.js in the System app to match
>>> the value to actual setEnabled() method and do other stuff if it
>>> seems
>>> reasonable to do in System app.
>>> Using mozSettings value as a mean of cross-domain communication is
>>> not
>>> elegant, yet I believe with the current situation this is the only
>>> way.
>>> Kaze, would that be a problem for you? How soon do you think you can
>>> apply the Settings app with these rules?
>>> --
>>> Tim Guan-tin Chien, Front-end Dev, Mozilla Corp. (Taipei)
