Ticket #5459 (closed defect: duplicate)

Opened 7 years ago

Last modified 6 years ago

second circle in sugar home view provides false information

Reported by: sj Owned by: mtd
Priority: high Milestone: 8.2.0 (was Update.2)
Component: sugar Version:
Keywords: Cc: marco
Action Needed: code Verified: no
Deployments affected: Blocked By:


Interface : Currently two circles can still show up in sugar, one indicating a connection to an access point, and another with the name of a mesh channel. Are we actually connecting to both? The access point indicates which mesh channel it is connecting over, and yanni suggests the mesh-circle contains no useful extra data; when the mesh channel listed for the gray mesh circle is different from the channel in the metadata for the access point, the latter is correct.

To reproduce : when you connect to a mesh that has no school server, the icon will blink for a long time. within this window, if you connect to an access point, the mesh circle will continue to blink in the mesh view, and a gray circle for that mesh channel will show up below the donut, even as the access point connects.

This makes some users think they can select both a mesh and an access point (when one will usually knock you off of the other), and makes it harder to debug network issues.

Change History

Changed 7 years ago by jg

  • cc marco added
  • owner changed from jg to Eben
  • component changed from distro to interface-design
  • milestone changed from Never Assigned to Future Release

Changed 7 years ago by Eben

  • status changed from new to closed
  • resolution set to fixed

The new design for devices positions the mesh (and it's channels) as a device instead of an item within the Neighborhood, which is more appropriate and should alleviate this problem.

Changed 7 years ago by marco

  • status changed from closed to reopened
  • resolution deleted
  • component changed from interface-design to sugar

This is not fixed actually. There are inconsistencies between the network state and the UI. To reproduce click first on a mesh channel and then on an access point. The mesh icon is blinking and in the device view, the palette shows that we are connecting to the mesh.

Changed 6 years ago by wad

Believed to be related to #6872

Changed 6 years ago by carrano

I observe that a second circle appears after a fresh install of build 703, but it disappears on consecutive reboots.

Changed 6 years ago by Eben

  • owner changed from Eben to mtd
  • priority changed from normal to high
  • status changed from reopened to new
  • milestone changed from Future Release to Update.2

I'm reassigning this to mtd, who has taken on the task of fixing the mesh/AP devices and behaviors. This task, obviously, includes making the states shown in the device palettes/frame consistent with the states shown in the Neighborhood. Feel free to assign this back if you have specific questions on the desired behavior.

I'm also bumping it into the U.2 milestone, since the changes in the devices needs to be done as part of the UI redesign.

Changed 6 years ago by marco

  • keywords 8.2.0:? needs-testing added

Changed 6 years ago by mtd

  • next_action set to design

Changed 6 years ago by mstone

  • owner changed from mtd to Eben
  • next_action changed from design to communicate

Eben, could you please explain what we have here now, what we want to have, and any stuff we need to know to document this?

Changed 6 years ago by Eben

  • owner changed from Eben to mtd
  • next_action changed from communicate to code

OK, here's my bulleted summary of the desired behavior. For reference:

  1. Mesh: http://wiki.laptop.org/go/Designs/Frame#09
  2. AP: http://wiki.laptop.org/go/Designs/Frame#10


  • The "mesh" is treated as a device, and will always be present in the Frame.
  • The mesh device is rendered in XO colors when turned on, and white when turned off.
  • The secondary text of the palette should indicate the state of the mesh connection.
  • The secondary palette should allow one to set the mesh channel.
  • When in the "connecting" state, the Mesh icon should pulse.
  • In the short term, any AP should enter the "disconnecting" state when the mesh is turned on. In the future, when it's possible to connect to both Mesh and AP at the same time, this won't be true.
  • In the short term, there will be no "Turn off"(/Turn on) option on the mesh device; Instead, the mesh device will automatically turn off when a connection to an AP is initiated. In the future, when they are independent, we'll add this option.


  • APs are treated as external devices, and as such are "connected to", and only appear when a connection exists (in any state)
  • APs are rendered in their own (hashed) colors at all times.
  • The secondary text of the palette should indicate the state of the AP connection.
  • AP icons should pulse when in the "connecting" state.
  • In the short term, when the mesh device is turned on, the AP should enter the "disconnecting" state. In the future they will be independent.
  • The AP device in the frame should always match the state of the device in the Neighborhood, including colors, state, pulsing, etc.

Changed 6 years ago by mtd

  • blocking 6995 added


Thanks for the summary. This sounds like it's completely subsumed by #6995 (or vice-versa). Am I right?


Changed 6 years ago by mtd

  • keywords 8.2.0:? needs-testing removed
  • status changed from new to closed
  • resolution set to duplicate
  • blocking 6995 removed

sj/marco, I think this is a dupe and eben seems to agree, so I'll close...I'll cc you on #6995 at the risk of spamming you a bit more...

Note: See TracTickets for help on using tickets.