#2866 HIGH 9.1.0: Network Manager GUI doesn't report success or failure

[Zarro Boogs per Child]

#2866: Network Manager GUI doesn't report success or failure
---------------------+------------------------------------------------------
  Reporter:  gnu     |       Owner:  mtd                              
      Type:  defect  |      Status:  new                              
  Priority:  high    |   Milestone:  9.1.0                            
 Component:  sugar   |     Version:  Development build as of this date
Resolution:          |    Keywords:  rel-8.2.0:? rel-9.1.0:+          
  Verified:  0       |    Blocking:                                   
 Blockedby:          |  
---------------------+------------------------------------------------------
Changes (by mtd):

  * keywords:  => rel-8.2.0:? rel-9.1.0:+
  * version:  Build 542 => Development build as of this date
  * milestone:  Retriage, Please! => 9.1.0


Comment:

 Replying to [comment:13 Eben]:
 >  1. We need adequate feedback when connecting.  The icons (in the
 Neighborhood, and in the Frame) should pulse to indicate connection is in
 progress.  If we have more detailed info, this can be shown in the
 palette. (I'd need more specific info about what info we have to spec this
 better.)

 I'm not too familiar with the reason it doesn't pulse when in the Frame
 (possibly it's just that it doesn't get added to the Frame before it's
 connected), but as it pulses in the Neighborhood I can't see why this'd be
 hard.  As to what additional info is available, offhand I don't know but
 we can see.

 >  2. When a connection is established, we should show a notification to
 indicate this, and pulsing should stop.

 Sure - sounds like Sugar Notifications are easy to do from what you've
 told me on IRC, so that shouldn't be a big deal.

 >  3. When a connection fails, we should show a notification to indicate
 this, and pulsing should stop.  Also, the icon should be badges with a
 notification badge, and the palette should offer "Retry" and "Cancel"
 actions.

 Sure.  At a minimum we might be able to usefully define failure as "the
 AP/nm device state went straight from ACTIVATING to INACTIVE", which I
 think is the only non-obvious (to me) code path here.

 >  4. We should add some additional status info to the device palette,
 such as the the IP address.  (I'm open to suggestions on what we should
 actually be exposing)

 Easy, I'd think.

 > Martin, these items all relates to your work on AP/Mesh devices, so I'm
 assigning to you.

 Sure.  To ensure nobody feels restricted from working on this, I'll note I
 haven't really touched the AP code itself in the course of dealing with
 #6933 (mesh devices), so the AP-related changes could be done
 independently.

 >  I'll let you triage this ticket accordingly.

 I don't know what I can get done before the 0.81.3 freeze.
 Disappointingly (I know it's a small amount of code, but it's a good
 amount of knowledge to do it right, and I've already got other bugs so I
 don't want to over-promise) I'd say expect nothing for 8.2.0 :( (of course
 then you can only be surprised).

 I've taken a stab at triage based on my read of the wrap-up of
 http://lists.laptop.org/pipermail/devel/2008-June/015541.html , but
 corrections welcome.

-- 
Ticket URL: <http://dev.laptop.org/ticket/2866#comment:14>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system