On Wed, May 19, 2010 at 1:47 AM, James Cameron <qu...@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. > The patch was created before that the feature has been backported > Also, the same changes apply to other wireless network types, not just > 3G, so I don't think "3G Support" is the right description. > Maybe you are right, but the feature has this name: http://wiki.sugarlabs.org/go/Features/3G_Support > 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 > > Backporting this patch to 0.84 is not trivial, i will try. > > 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. > Maybe we have to shown two messages, the error message ("PPP_DISCONNECT") and a possible solution to the user ("Check the APN configuration.") > > 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. > > 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 I have consult this list. We try to catch just the most common messages. > > 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. > > I'd like to know which error messages we should show in each case. Thanks for your comments/corrections! > -- > James Cameron > http://quozl.linux.org.au/ > -- Ing. Daniel Castelo Plan Ceibal - Área Técnica Avda. Italia 6201 Montevideo - Uruguay. Tel.: 601.57.73 Interno 2228 E-mail : dcast...@plan.ceibal.edu.uy
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel