[Sugar-devel] 3G Support: show connection errors- Patch 1759

[Tomeu Vizoso]

On Wed, May 19, 2010 at 06:47, James Cameron <quozl at laptop.org> wrote:
> On Tue, May 18, 2010 at 04:26:44PM -0300, Daniel Castelo wrote:
>> I have this ticket pending, could you give your feedback? Thanks!!!
>> http://bugs.sugarlabs.org/ticket/1759
>>
>> This patch improves the feature 3G Support (added in 0.88).
>
> It was also backported to 0.84, so the mention of 0.88 is probably
> unnecessarily restrictive.
>
> Also, the same changes apply to other wireless network types, not just
> 3G, so I don't think "3G Support" is the right description.
>
> By the way, if you produce a 0.84 re-spin, then I can easily test it for
> you.  See sucrose-0.84 branch in
> git://git.sugarlabs.org/sugar/mainline.git
>
>> Includes:
>> Show the connection errors
>> Apply Eben's Mockup:  http://wiki.sugarlabs.org/go/File:3G_device.png
>>
>>
>> ---
>> index 94a4293..995446c 100644
>> --- a/extensions/deviceicon/network.py
>> +++ b/extensions/deviceicon/network.py
>> @@ -267,35 +282,89 @@ class GsmPalette(Palette):
>
> ...
>
>> +    def _get_error_by_nm_reason(self, reason):
>> +        if reason in [network.NM_DEVICE_STATE_REASON_NO_SECRETS,
>> network.NM_DEVICE_STATE_REASON_GSM_PIN_CHECK_FAILED]:
>> +            message = _('The Pin/Puk configuration is not valid.')
>
> There can be other explanations for this reason, such as incorrect SIM
> inserted.  It is better to stick to the meaning; "PIN check failed."
>
>> +        elif reason in [network.NM_DEVICE_STATE_REASON_PPP_DISCONNECT,
>> network.NM_DEVICE_STATE_REASON_PPP_FAILED]:
>> +            message = _('Check the APN configuration.')
>
> While APN is indeed known to cause PPP_DISCONNECT and PPP_FAILED, there
> are many other reasons, and so it is incorrect to specifically identify
> APN as the only cause.  An invalid APN is a common cause, but not the
> only cause.  Another cause commonly seen is lack of radio signal or
> antenna.
>
> Also, "Access Point Name (APN)" is how it is described in the Modem
> Configuration control panel, and so that is how you should describe it
> in a message.
>
>> +        elif reason in [network.NM_DEVICE_STATE_REASON_MODEM_NO_CARRIER]:
>> +            message = _('Check the tel number configuration.')
>
> Again, this is not the only reason this can occur.

Maybe we could think about a standard way to hint for the most
probable reason? Maybe a second line?

In any case, maybe we would only know what is more useful for our
users after some real testing.

Btw, the patch has several formatting errors such as indentation and
too long lines, either Daniel should fix them by himself or somebody
could help him spot them. Pylint should catch those and probably more.

Regards,

Tomeu

> Also, "tel number" is not the way it is described in the control panel,
> it uses "Number".
>
>> +        elif reason in [network.NM_DEVICE_STATE_REASON_MODEM_DIAL_TIMEOUT]:
>> +            message = _('Time out. Check the tel configuration')
>
> "tel number" should be "Number".
>
>> +        else:
>> +            message = _('Unexpected error.')
>
> More should be handled.
>
>> +        return message
>> +
>>      def __toggle_state_cb(self, menuitem):
>>          if self._current_state == _GSM_STATE_NOT_READY:
>>              pass
>
> ...
>
>> index 3a949da..579ed8d 100644
>> --- a/src/jarabe/model/network.py
>> +++ b/src/jarabe/model/network.py
>> @@ -54,6 +54,13 @@ NM_ACTIVE_CONNECTION_STATE_UNKNOWN = 0
>>  NM_ACTIVE_CONNECTION_STATE_ACTIVATING = 1
>>  NM_ACTIVE_CONNECTION_STATE_ACTIVATED = 2
>>
>> +NM_DEVICE_STATE_REASON_NO_SECRETS = 7
>> +NM_DEVICE_STATE_REASON_PPP_DISCONNECT = 13
>> +NM_DEVICE_STATE_REASON_PPP_FAILED = 14
>> +NM_DEVICE_STATE_REASON_MODEM_NO_CARRIER = 25
>> +NM_DEVICE_STATE_REASON_MODEM_DIAL_TIMEOUT = 26
>> +NM_DEVICE_STATE_REASON_GSM_PIN_CHECK_FAILED = 34
>
> You seem to have selected a subset of available NM_DEVICE_STATE_REASON
> values.  A larger list is at
>
> http://projects.gnome.org/NetworkManager/developers/spec.html
>
> and shows several reasons that an Australian deployment would expect to
> encounter with the Australian wireless broadband provider networks.
>
> I think more reasons should be handled.
>
> --
> James Cameron
> http://quozl.linux.org.au/
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>