second circle in sugar home view provides false information

[sj]

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.

[Eben]

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.

[marco]

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.

[wad]

Believed to be related to #6872

[carrano]

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

[Eben]

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.

[mstone]

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?

[Eben]

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

Mesh:

• 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:

• 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.

[mtd]

Eben,

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

Martin

[mtd]

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...