Opened 7 years ago

Closed 6 years ago

#5459 closed defect (duplicate)

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
Blocked By: Blocking:
Deployments affected: Action Needed: code
Verified: no

Description

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 (12)

comment:1 Changed 7 years ago by jg

  • Cc marco added
  • Component changed from distro to interface-design
  • Milestone changed from Never Assigned to Future Release
  • Owner changed from jg to Eben

comment:2 Changed 7 years ago by Eben

  • Resolution set to fixed
  • Status changed from new to closed

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.

comment:3 Changed 7 years ago by marco

  • Component changed from interface-design to sugar
  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:4 Changed 7 years ago by wad

Believed to be related to #6872

comment:5 Changed 7 years ago by carrano

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

comment:6 Changed 6 years ago by Eben

  • Milestone changed from Future Release to Update.2
  • Owner changed from Eben to mtd
  • Priority changed from normal to high
  • Status changed from reopened to new

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.

comment:7 Changed 6 years ago by marco

  • Keywords 8.2.0:? needs-testing added

comment:8 Changed 6 years ago by mtd

  • Action Needed set to design

comment:9 Changed 6 years ago by mstone

  • Action Needed changed from design to communicate
  • Owner changed from mtd to Eben

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?

comment:10 Changed 6 years ago by Eben

  • Action Needed changed from communicate to code
  • Owner changed from Eben to mtd

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.

comment:11 Changed 6 years ago by mtd

  • Blocking 6995 added

Eben,

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

Martin

comment:12 Changed 6 years ago by mtd

  • Blocking 6995 removed
  • Keywords 8.2.0:? needs-testing removed
  • Resolution set to duplicate
  • Status changed from new to closed

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.