Add a mesh device to the frame and remove mesh devices from Neighborhood view

[mtd]

The new design at http://wiki.laptop.org/go/Designs/Frame#09 calls for a mesh device to be added to the frame, and for mesh devices to be hidden from the Neighborhood view.

[mtd]

Status update: An initial version of this is done in http://dev.laptop.org/git?p=users/mdengler/sugar;a=shortlog;h=mesh-icon-6995 . It is not ready for review yet due to the outstanding items below.

The outstanding items are:

1a) mesh tray icons don't pulse when activating as eben wants them to

1b) no network tray icons pulse when activating

2) I have not tested a lot of the transitions, so there might be some problems/state that isn't accurately reflected in the icon/palette

3) I believe either the sugar/src/model/devices/network/mesh.py or sugar/src/hardware/nmclient.py should change the channel it reports when the (mesh) device is activating; I believe it's currently reporting the *last* successful channel set, not the *desired/requested* channel. Clearly if the desired/requested channel has been tried and failed then another channel should be reported, but right now if the user is on mesh channel 11 and clicks on, say "6" to change to mesh channel 6, then channel 6 is requested from mesh-model.py, but until it succeeds mesh-model reports channel 11.

[mtd]

I have all the behaviors mentioning in #5459 coded; remaining work is a) tidyup (I've had to get knee-deep into sugar's NetworkManager interaction); b) some coordination about some sugar vs. sugar-toolkit code placement questions; and c) draw up test cases and run them myself before asking for a review. The patch is not tiny.

[mtd]

(In #5459) Eben,

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

Martin

[mtd]

(In #5459) 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...

[mtd]

(In #6135) This is done (though it will change with NM 0.7):

http://dev.laptop.org/~mdengler/6995/6995_screenshot_15.png

...but I'd rather release with #6995. Any objections (by the reporters, especially) to closing this and tracking it there? The only downside I can see is that #6995 might not make it into 8.2.0/update.2. I could always make a patch just for this issue, though.

[mstone]

Martin's screenshots are so attractive that we're willing to test out his work and, assuming it more-or-less succeeds, to include it. :)

[mtd]

(In #3993) Sorry, forgot to update this - #6995 fixes this, AFAICS. A few NM signals/property change notifications were not being added/emitted properly, and the order of initialization was not ideal (especially, it assumed the network connections were being made via the Sugar UI, so pre-existing connections would not necessarily be displayed correctly).

For example, consider:

http://dev.laptop.org/git?p=users/mdengler/sugar;a=commitdiff;h=dc266fd234fb4981f2a047ecdc34a1fc34fa9588

...and...

http://dev.laptop.org/git?p=users/mdengler/sugar;a=blobdiff;f=src/model/devices/network/mesh.py;h=427ca7218a088aacd0a37e2a90172d9fdb6d33de;hp=36626e69c975bad28677dd04c7512ea02eaab780;hb=mesh-icon-6995;hpb=d04f20fc1c895c514c41b3f812733061e9c77df6

[marco]

(In #6135) Dup per mtd comment.

[mtd]

(In #7690) I've just landed the fix suggested by m_stone in sugar git (approved by marco, so thanks to you both).

eben's pretty adamant that we *not* turn of the radio using the wireless / mesh icons, so I don't think this is a blocker for #6995 any more.

We do have the controlpanel option to turn off the radio, though, and the extreme power management mode does the same thing, so perhaps this deserves a release note or something (as the mesh device won't come back up if people turn off the radio in either of these two ways).

FWIW, a terrible hack that I could do to get everything to come back up is here: http://dev.laptop.org/git?p=users/mdengler/sugar;a=commitdiff;h=712f2b584d06821a6e49bdebe23f70ed3a950346

[gnu]

(Comments copied from http://dev.laptop.org/ticket/7690#comment:6 and :7)

I'm confused about this remark:

eben's pretty adamant that we *not* turn of the radio using the wireless / mesh icons

His design at http://wiki.laptop.org/go/Designs/Frame#09 shows a "Turn off" action for the Mesh icon, and a "Disconnect" action for the access point icon. I think these actions should work!

If they do work, what is the point of having the WiFi chip sitting there burning 0.8 watts of our precious battery fluids when both the mesh and the access point are off?

Aha, I think I understand. Eben modified his design with this comment buried in another bug: http://dev.laptop.org/ticket/5459#comment:10

The problem with eliminating the "mesh off" button is that we lose huge power saving opportunities.

I don't think Eben realized that when he made that design choice. See the comments in #5144. With the mesh off and an access point on, we save small or medium amounts of power -- and have an opportunity to power down the WiFi chip when the lid is closed, which saves major amounts of power while suspended (basically the laptop lasts much more than 8 hours in suspend). With both the mesh and the access point off, the WiFi chip can also be powered down during suspend -- or all the time.

In Eben's modified design, the only way to turn off the mesh is to turn on an access point. That's counter-intuitive, and if there is no access point visible, there is no way to turn off the mesh at all -- which means we burn full power all the time. The "Turn off" mesh action from the original design should be reinstated.

[gnu]

Note also #1406 (XO needs "Airplane Mode"). There should be an easy and obvious way to turn off all the wireless equipment for use on airplanes. Merely going to the icons in the Frame and turning each of them off *should* suffice.

[mtd]

Replying to gnu:

Note also #1406 (XO needs "Airplane Mode"). There should be an easy and obvious way to turn off all the wireless equipment for use on airplanes. Merely going to the icons in the Frame and turning each of them off *should* suffice.

There is a option in the control panel's "Network" section that allows one to turn the radio off/on. There is still #7690, but I think it's ancillary to your main concern right now.

[mtd]

Replying to mtd:

Replying to gnu:

Note also #1406 (XO needs "Airplane Mode"). There should be an easy and obvious way to turn off all the wireless equipment for use on airplanes. Merely going to the icons in the Frame and turning each of them off *should* suffice.

There is a option in the control panel's "Network" section that allows one to turn the radio off/on. There is still #7690, but I think it's ancillary to your main concern right now.

I take it you knew about that option. So are you saying that it's not obvious enough? I tend to agree that it'd be nice if the "Turn off" mesh icon palette entry should turn off the radio, to make it easier. But as we've been discussing in #7690, that design has not been accepted. As I mentioned there, if we want to get anything changed we should probably take the (general) discussion out to sugar@ or devel@.

[mtd]

I've inverted the blocking/blocker relationship between this bug (#6995) and 2866 and 3993, in order to slim down the patches for each.

[mtd]

(In #2866) I've decided to break this work out from #6995, since it's a bit simpler than #6995 and it will make the #6995 patch simpler if I can get this one out of the way first.

I'd like anyone interested to consider testing my patch on their joyride-stream XO by doing:

cd /home/olpc
git-clone git://dev.laptop.org/users/mdengler/sugar xo-sugar-2866
cd /usr/share/sugar/shell
for dir in hardware model view ; do sudo mv $dir ${dir}.orig ; sudo ln -s /home/olpc/xo-sugar-2866/src/${dir} ; done                                              

You should get results like this:

http://dev.laptop.org/~mdengler/2866/2866_screenshot_10.png

Open issues:

1) notifications show up as a black square. There must be some flaw in my notification code: http://dev.laptop.org/git?p=users/mdengler/sugar;a=blob;f=src/view/devices/network/notifications.py;h=20f74754778176e20728a055ca129aa00f2b57c5;hb=a73a2a91b40f48214bd62324d7e203a79cebf53d#l50 2) When one tries to join a mesh, the frame's mesh icon & palette are empty (mouse over the "empty" space just to the left of the speaker icon after clicking on a mesh icon in the Mesh/Neighborhood view to see what I mean).

They should be easy but if I never get anyone testing this it'll keep taking forever.

[mtd]

I've inverted the blocking/blocker relationship between this bug (#6995) and 2866 and 3993, in order to slim down the patches for each and more truly represent the dependencies.

[Eben]

Replying to gnu:

(Comments copied from http://dev.laptop.org/ticket/7690#comment:6 and :7) I'm confused about this remark:

eben's pretty adamant that we *not* turn of the radio using the wireless / mesh icons

His design at http://wiki.laptop.org/go/Designs/Frame#09 shows a "Turn off" action for the Mesh icon, and a "Disconnect" action for the access point icon. I think these actions should work!

Me too!

Aha, I think I understand. Eben modified his design with this comment buried in another bug: http://dev.laptop.org/ticket/5459#comment:10 The problem with eliminating the "mesh off" button is that we lose huge power saving opportunities. I don't think Eben realized that when he made that design choice. See the comments in #5144. With the mesh off and an access point on, we save small or medium amounts of power -- and have an opportunity to power down the WiFi chip when the lid is closed, which saves major amounts of power while suspended (basically the laptop lasts much more than 8 hours in suspend). With both the mesh and the access point off, the WiFi chip can also be powered down during suspend -- or all the time.

This is not a design choice; it is a design concession. The preferred design, and my intent, remains as the wiki states, with a "Disconnect" option on APs and the ability to "Turn off" the mesh. I made the adjustment after being told that, in fact, these actions don't exist in the current network manager; instead, they were actually implemented in the manner I described in my concession, with the deactivation of one causing the activation of the other (due to the fact that there is no way to "disconnect", as the comments in the source indicated.)

In Eben's modified design, the only way to turn off the mesh is to turn on an access point. That's counter-intuitive, and if there is no access point visible, there is no way to turn off the mesh at all -- which means we burn full power all the time. The "Turn off" mesh action from the original design should be reinstated.

I agree. It's entirely counter-intuitive! Unfortunately, its the current technical limitation. NM has no "disconnect" because in the past, disconnect has been synonymous with "turn the radio off" or "connect to this other AP I care about". This is not so in our case, since we use the radio for these two (in theory) independent functions. I do not think it wise to brush past this distinction, providing "Disconnect" and "Turn off" actions on the respective devices which share a common action of turning the radio off, since this action naturally affects both devices, and not only the one which the user intended to deactivate.

[mtd]

Replying to Eben:

Replying to gnu:

In Eben's modified design, the only way to turn off the mesh is to turn on an access point. That's counter-intuitive, and if there is no access point visible, there is no way to turn off the mesh at all -- which means we burn full power all the time. The "Turn off" mesh action from the original design should be reinstated.

I agree. It's entirely counter-intuitive! Unfortunately, its the current technical limitation. NM has no "disconnect" because in the past, disconnect has been synonymous with "turn the radio off" or "connect to this other AP I care about". This is not so in our case, since we use the radio for these two (in theory) independent functions. I do not think it wise to brush past this distinction, providing "Disconnect" and "Turn off" actions on the respective devices which share a common action of turning the radio off, since this action naturally affects both devices, and not only the one which the user intended to deactivate.

I've said before on IRC but not in this type of forum: disconnect/turn off in the wireless/mesh palette meaning "turn off the radio right now" is:

1a. practically intuitive, as far as the user wants to stop using whichever of the mesh/wireless that they're using;

1b. not going to become less so anytime soon, as they have no way of using the other of the wireless/mesh at the same time, so they can't be surprised that it "also" goes off;

2. very useful, as power consumption is significantly affected.

Meta-argument: arguments about "intuition" regarding the mesh seem to me very optimistic about the evolutionary speed of human intuition, as very few people have a mesh now (and fewer of those need to care: it'd just have been automatically started for them). This weakens/defeats the "mesh" part of my point 1., but not at all the wireless part (which is pretty intuitive, and the current implementation is not at all).

If there has been one "design concession" already, let's trade it for another - "Disconnect" on the wireless palette - that saves power and does exactly what every other "turn off wireless" button on every other laptop does.

Eben, I thank you again for the great design in general and all your effort and help with this bug in particular, so please forgive if my arguments come across as harsh - it's not my intention.

[gregorio]

Hi Guys,

Were out of time. If we have a solution coded and ready let's get it in ASAP. If not let's document the way it works in the release notes. You can put it here: http://wiki.laptop.org/go/Release_Notes/8.2.0#Network-related_issues or create a new section or maybe put it in the tips and tricks area.

I'm going to take the blocking status off this. Once its documented let's move the milestone to 9.1 and try to get it right the next time.

Thanks,

Greg S

[mtd]

(In #6944) As part of submitting a patch for #3993, I'm convinced this is indeed part of #6995, but it's the #3993 part of that bug. Changing the blocked-by appropriately.

[mtd]

HoboPrimate has suggested in #2866 that the HIG's level indicators could/should be used; perhaps we should use the DISCRETE style (like in the small progress bar here: http://dev.laptop.org/~mdengler/6995/6995_screenshot_50.png ) for the main "strength" level indicators in the mesh/wireless palette, and thus can use the normal, non-discrete progress bar for the "Connecting" stages.

Using the discrete style is easy. Making it look exactly like the HIG's guidlines is an unknown (to me) amount of work.

Thoughts on this?

[mtd]

(In #6944) In joyride-2369, the first test case is passed. The second test case is failed.

It appears I was wrong about #3993 being the root problem here.

The original problem report - attempt connection to slow AP, then successfully connect to fast AP, and sugar shows one as connected to slow AP - is fixed. However this very similar problem report is not: attempt connection to slow AP #1, then attempt connection to slow AP #2, and sugar shows one as connecting to slow AP #1.

So this is technically fixed but I don't think it should be closed.

I also think it *will* be closed by #6995. I'm syncing this bug's tags with #6995's, but I think those need updating...

[mtd]

eben asked me to move the milestone to 8.2.1 and bump the priority after I said that I had promised to un-bitrot this patch this weekend.

[thomaswamm]

I was going to create a ticket about weirdnesses in the networking user interface seen in beta build 8.2-760, but this existing ticket hints it is all still a work in progress. So I will go away til you guys finish changing things.

[mtd]

(In #8592) Replying to thomaswamm:

The symptom of AP and mesh icons both showing in frame was previously reported in #4074, so this might be a regression.

I don't think #4074 was ever really fixed; consider #6944 (and also #5459, #6872).

I'll update #4074. Perhaps we should close this as a dupe.

[mchua]

(In #7879) The blockers are not actually blockers, says cjb...

[mstone-xmlrpc]

Pushing out to 9.1.0, per edmcnierney's request.

[gnu]

On the short feature list for the 9.1.0 release is the ability to turn off the mesh device from the Frame, to save power. With an obvious control (like a "Turn off" menu item on the frame mesh icon's popup). Whether or not an access point is visible from the laptop (currently to turn off mesh, you have to pick an AP).

I'm running debxo-0.4 which uses gnome-nm-applet 0.6.6,which has under its right- button menu an "Enable Networking" checkbox and an "Enable Wireless" checkbox, which works. This must mean that its NetworkManager (0.6.6-2) is capable of disabling all wireless. It does not appear to have independent controls for enabling and disabling individual wireless devices.

At any rate, if this is to be fixed for 9.1.0, both the Sugar GUI will need to add the AP and mesh disable menu items, and NM will need to have commands that turn off the individual wireless devices (msh0 and eth0). What's the current status of each of those features?

[dsd]

(In #6944) Can't reproduce on 11.2.0, after quickly trying to connect to 2 APs, the colours shown in the frame device are correct (in terms of the 2nd AP clicked).