Re: [Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
On Wed, Jan 22, 2014 at 2:56 PM, Frederick Grose fgr...@gmail.com wrote: On Wed, Jan 22, 2014 at 6:03 AM, Daniel Narvaez dwnarv...@gmail.comwrote: On 21 January 2014 03:49, Frederick Grose fgr...@gmail.com wrote: On Mon, Jan 20, 2014 at 4:17 PM, Frederick Grose fgr...@gmail.comwrote: Fixes #4410 https://bugs.sugarlabs.org/ticket/4410 The 'Discard network history' button is peculiar to Sugar, and is destructive to all non-wireless connections, despite being in the 'Wireless' section of the control panel. In the proposed patch[0], the code variables and functions are renamed and coded to be specific to wireless connections. The 'Radio' checkbox instruction and 'Discard ...' button are reworded to avoid confusion over their state and actions.[1] If wireless hardware is not present on the system, the 'Wireless' section of the control panel is excluded.[2] [0,1,2] - https://github.com/sugarlabs/sugar/pull/228 Daniel Narvaez wrote via notificati...@github.com It seems like the code is handling adhoc networks specially, but I didn't find an explanation of that change. Can you please elaborate on it? The current code at, https://github.com/sugarlabs/sugar/blob/master/src/jarabe/model/network.py#L835 tests for sugar-internal connections by reading the connection_id string. The new code is specific to wireless connections. The first condition, the presence of a wifi_settings list, avoids 7 of the 7 sugar-internal connections on XO-1. The sugar ad hoc connections are avoided by a second condition, the same test as in the currrent code, connection_id.startswith(ADHOC_CONNECTION_ID_PREFIX). So to make that more explicit, compared to the old code we are *not* clearing anymore gsm, mesh and xs_mesh networks. Is that correct? The sugar-internal gsm, mesh, xs_mesh connections are not cleared in the old or proposed, new code. Do we have another way to clear gsm? There is a separate control panel for GSM modems. I'm not very familiar with it though. I'm not too sure we should stop clearing mesh and xs_mesh. It is wifi too and it might play a role in the unbreak procedures people have describing in this thread. See above (the sugar-internal mesh and gsm are not cleared). I suppose someone might create another such connection at a command line. What's the harm of doing that? Clearing non-sugar-internal mesh connections should be ok (as that is the current behavior). GSM matters might better be handled on its own control panel. So yes, GSM users creating custom, non-sugar-gsm connections would be affected if they depended on the 'Discard network history' button. The modemconfiguration panel, though, seems to use only the one GSM_CONNECTION_ID = 'Sugar Modem Connection' from jarabe.model.network. So perhaps best for now, to continue to discard non-sugar GSM connections, and test for other GSM connections before excluding that control panel subsection. This seems too much of a corner case (along with other manually created, non-wireless connections). I'll close the pull request and resubmit changes sequentially as recommended in the other note. Thanks for reviewing, --Fred There is a new pull request at https://github.com/sugarlabs/sugar/pull/234 And a feature page here: http://wiki.sugarlabs.org/go/Features/Network_control_panel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
On 21 January 2014 03:49, Frederick Grose fgr...@gmail.com wrote: On Mon, Jan 20, 2014 at 4:17 PM, Frederick Grose fgr...@gmail.com wrote: Fixes #4410 https://bugs.sugarlabs.org/ticket/4410 The 'Discard network history' button is peculiar to Sugar, and is destructive to all non-wireless connections, despite being in the 'Wireless' section of the control panel. In the proposed patch[0], the code variables and functions are renamed and coded to be specific to wireless connections. The 'Radio' checkbox instruction and 'Discard ...' button are reworded to avoid confusion over their state and actions.[1] If wireless hardware is not present on the system, the 'Wireless' section of the control panel is excluded.[2] [0,1,2] - https://github.com/sugarlabs/sugar/pull/228 Daniel Narvaez wrote via notificati...@github.com It seems like the code is handling adhoc networks specially, but I didn't find an explanation of that change. Can you please elaborate on it? The current code at, https://github.com/sugarlabs/sugar/blob/master/src/jarabe/model/network.py#L835 tests for sugar-internal connections by reading the connection_id string. The new code is specific to wireless connections. The first condition, the presence of a wifi_settings list, avoids 7 of the 7 sugar-internal connections on XO-1. The sugar ad hoc connections are avoided by a second condition, the same test as in the currrent code, connection_id.startswith(ADHOC_CONNECTION_ID_PREFIX). So to make that more explicit, compared to the old code we are *not* clearing anymore gsm, mesh and xs_mesh networks. Is that correct? Do we have another way to clear gsm? I'm not too sure we should stop clearing mesh and xs_mesh. It is wifi too and it might play a role in the unbreak procedures people have describing in this thread. What's the harm of doing that? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
By the way I think we should probably not block Frederick patch on the UI discussion about being able to forget networks one by one. On 22 January 2014 12:03, Daniel Narvaez dwnarv...@gmail.com wrote: On 21 January 2014 03:49, Frederick Grose fgr...@gmail.com wrote: On Mon, Jan 20, 2014 at 4:17 PM, Frederick Grose fgr...@gmail.comwrote: Fixes #4410 https://bugs.sugarlabs.org/ticket/4410 The 'Discard network history' button is peculiar to Sugar, and is destructive to all non-wireless connections, despite being in the 'Wireless' section of the control panel. In the proposed patch[0], the code variables and functions are renamed and coded to be specific to wireless connections. The 'Radio' checkbox instruction and 'Discard ...' button are reworded to avoid confusion over their state and actions.[1] If wireless hardware is not present on the system, the 'Wireless' section of the control panel is excluded.[2] [0,1,2] - https://github.com/sugarlabs/sugar/pull/228 Daniel Narvaez wrote via notificati...@github.com It seems like the code is handling adhoc networks specially, but I didn't find an explanation of that change. Can you please elaborate on it? The current code at, https://github.com/sugarlabs/sugar/blob/master/src/jarabe/model/network.py#L835 tests for sugar-internal connections by reading the connection_id string. The new code is specific to wireless connections. The first condition, the presence of a wifi_settings list, avoids 7 of the 7 sugar-internal connections on XO-1. The sugar ad hoc connections are avoided by a second condition, the same test as in the currrent code, connection_id.startswith(ADHOC_CONNECTION_ID_PREFIX). So to make that more explicit, compared to the old code we are *not* clearing anymore gsm, mesh and xs_mesh networks. Is that correct? Do we have another way to clear gsm? I'm not too sure we should stop clearing mesh and xs_mesh. It is wifi too and it might play a role in the unbreak procedures people have describing in this thread. What's the harm of doing that? -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
In F20 you have list with checkboxes near each item, so you can click all the checkboxes and then press the Forget button. On 22 January 2014 02:42, Paul Fox p...@laptop.org wrote: daniel wrote: On 22 January 2014 01:04, James Cameron qu...@laptop.org wrote: On Wed, Jan 22, 2014 at 12:41:04AM +0100, Daniel Narvaez wrote: I'm referring to this patch, I couldn't find it before. https://github.com/sugarlabs/sugar/pull/153 It's actually per network, not per device, so it only forgets present networks. Can you explain why we need to be able to forget non-present ones? To prevent a host from automatically connecting to a network that was previously available and connected to, but is not at the moment, due to distance or the network being off. This may be done because of a change of ownership of a host, or a change in the trust level of a network. Ok. The button is not really a good UI for that use case but it's probably something we don't want to regress. Is there any way at all to restore that security feature after removal the Discard network history button? Not that I can think of, other than nmcli. So... I think we need design input here. Would a history list with a forget button a la GNOME be a good way handle that use case? i've only seen the last few messages in this thread, so my comment may be off-base, but: i've always found the networkmanager UI to be sorely lacking. i often find that the network list has grown quite long, including things like linksys and netgear (i wonder where _those_ were?), and every starbucks or airport wifi i've visited in the last 6 months. to unclutter my UI involves at least 3 clicks per network (or maybe 4: scroll, select, delete, confirm). i've always wanted it to be a select all the networks you'd like to delete interface instead. part of the issue is that the remembered networks are remembered even if a previous connection attempt was unsuccessful. this means that clicking on open networks that aren't really open will grow the list, as will selecting a non-guest network by mistake. paul =- paul fox, p...@laptop.org -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
On Wed, Jan 22, 2014 at 6:03 AM, Daniel Narvaez dwnarv...@gmail.com wrote: On 21 January 2014 03:49, Frederick Grose fgr...@gmail.com wrote: On Mon, Jan 20, 2014 at 4:17 PM, Frederick Grose fgr...@gmail.comwrote: Fixes #4410 https://bugs.sugarlabs.org/ticket/4410 The 'Discard network history' button is peculiar to Sugar, and is destructive to all non-wireless connections, despite being in the 'Wireless' section of the control panel. In the proposed patch[0], the code variables and functions are renamed and coded to be specific to wireless connections. The 'Radio' checkbox instruction and 'Discard ...' button are reworded to avoid confusion over their state and actions.[1] If wireless hardware is not present on the system, the 'Wireless' section of the control panel is excluded.[2] [0,1,2] - https://github.com/sugarlabs/sugar/pull/228 Daniel Narvaez wrote via notificati...@github.com It seems like the code is handling adhoc networks specially, but I didn't find an explanation of that change. Can you please elaborate on it? The current code at, https://github.com/sugarlabs/sugar/blob/master/src/jarabe/model/network.py#L835 tests for sugar-internal connections by reading the connection_id string. The new code is specific to wireless connections. The first condition, the presence of a wifi_settings list, avoids 7 of the 7 sugar-internal connections on XO-1. The sugar ad hoc connections are avoided by a second condition, the same test as in the currrent code, connection_id.startswith(ADHOC_CONNECTION_ID_PREFIX). So to make that more explicit, compared to the old code we are *not* clearing anymore gsm, mesh and xs_mesh networks. Is that correct? The sugar-internal gsm, mesh, xs_mesh connections are not cleared in the old or proposed, new code. Do we have another way to clear gsm? There is a separate control panel for GSM modems. I'm not very familiar with it though. I'm not too sure we should stop clearing mesh and xs_mesh. It is wifi too and it might play a role in the unbreak procedures people have describing in this thread. See above (the sugar-internal mesh and gsm are not cleared). I suppose someone might create another such connection at a command line. What's the harm of doing that? Clearing non-sugar-internal mesh connections should be ok (as that is the current behavior). GSM matters might better be handled on its own control panel. So yes, GSM users creating custom, non-sugar-gsm connections would be affected if they depended on the 'Discard network history' button. The modemconfiguration panel, though, seems to use only the one GSM_CONNECTION_ID = 'Sugar Modem Connection' from jarabe.model.network. So perhaps best for now, to continue to discard non-sugar GSM connections, and test for other GSM connections before excluding that control panel subsection. I'll close the pull request and resubmit changes sequentially as recommended in the other note. Thanks for reviewing, --Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
Before we go further discussing implementation, could someone explain why we need a global Discard wireless connections button vs the Forget item in the device palette which someone has mostly implemented already? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
On Wed, Jan 22, 2014 at 12:24:31AM +0100, Daniel Narvaez wrote: Before we go further discussing implementation, could someone explain why we need a global Discard wireless connections button vs the Forget item in the device palette which someone has mostly implemented already? Does Forget forget all networks, not just the ones present? Otherwise, the only reason I can think of is the installed base expectations and training issues. If I recall correctly, the main use case was inability to properly handle access points that either changed their passphrase or switched between encrypted and not-encrypted. If you add these test cases and pass them, I see no major problem with removing Discard -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
On 21 January 2014 03:15, Frederick Grose fgr...@gmail.com wrote: Daniel Narvaez wrote notificati...@github.com Where are you testing this? In Fedora 20, the list of devices seems to be available even if wireless is disabled [dnarvaez@vaio src]$ nmcli r WIFI-HW WIFI WWAN-HW WWAN enabled disabled enabled enabled [dnarvaez@vaio src]$ nmcli d DEVICE TYPE STATE wlp1s0 wifi unavailable lo loopback unmanaged I have not tested with the dbus service directly, but I'd expect nmcli to ultimately be using the dbus service to get this info. On the XO-1 with OLPC 13.2.0 and NetworkManager 0.9.8.1-3.git20130514.fc18 : -bash-4.2# nmcli nm RUNNING STATE WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running connected enabled enabledenabled disabled -bash-4.2# nmcli d DEVICE TYPE STATE msh0 802-11-olpc-mesh disconnected eth0 802-11-wireless connected -bash-4.2# nmcli nm wifi off RUNNING STATE WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running disconnectedenabled disabled enabled disabled -bash-4.2# nmcli d DEVICE TYPE STATE By the way, if I'm understanding things correctly, this issue is independent from the Discard network history one and might benefit from being handled separately. Given that the XO wouldn't use this feature (it has an internal wireless device) it seems like it should be implemented using the NetworkManager interfaces and somehow disabled on the XO, or, assuming the issue with devices not being listed with radio off is not driver related, more generically on old NetworkManager versions. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
On 22 January 2014 00:31, James Cameron qu...@laptop.org wrote: On Wed, Jan 22, 2014 at 12:24:31AM +0100, Daniel Narvaez wrote: Before we go further discussing implementation, could someone explain why we need a global Discard wireless connections button vs the Forget item in the device palette which someone has mostly implemented already? Does Forget forget all networks, not just the ones present? I'm referring to this patch, I couldn't find it before. https://github.com/sugarlabs/sugar/pull/153 It's actually per network, not per device, so it only forgets present networks. Can you explain why we need to be able to forget non-present ones? Otherwise, the only reason I can think of is the installed base expectations and training issues. If I recall correctly, the main use case was inability to properly handle access points that either changed their passphrase or switched between encrypted and not-encrypted. If you add these test cases and pass them, I see no major problem with removing Discard It seems like these cases would be covered by the patch I linked. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
On Wed, Jan 22, 2014 at 12:41:04AM +0100, Daniel Narvaez wrote: I'm referring to this patch, I couldn't find it before. https://github.com/sugarlabs/sugar/pull/153 It's actually per network, not per device, so it only forgets present networks. Can you explain why we need to be able to forget non-present ones? To prevent a host from automatically connecting to a network that was previously available and connected to, but is not at the moment, due to distance or the network being off. This may be done because of a change of ownership of a host, or a change in the trust level of a network. Is there any way at all to restore that security feature after removal the Discard network history button? Gnome provides a list of networks in a dialog and allows them to be removed individually. Edit Connections. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
On 22 January 2014 01:04, James Cameron qu...@laptop.org wrote: On Wed, Jan 22, 2014 at 12:41:04AM +0100, Daniel Narvaez wrote: I'm referring to this patch, I couldn't find it before. https://github.com/sugarlabs/sugar/pull/153 It's actually per network, not per device, so it only forgets present networks. Can you explain why we need to be able to forget non-present ones? To prevent a host from automatically connecting to a network that was previously available and connected to, but is not at the moment, due to distance or the network being off. This may be done because of a change of ownership of a host, or a change in the trust level of a network. Ok. The button is not really a good UI for that use case but it's probably something we don't want to regress. Is there any way at all to restore that security feature after removal the Discard network history button? Not that I can think of, other than nmcli. So... I think we need design input here. Would a history list with a forget button a la GNOME be a good way handle that use case? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
On Wed, Jan 22, 2014 at 01:22:39AM +0100, Daniel Narvaez wrote: So... I think we need design input here. Would a history list with a forget button a la GNOME be a good way handle that use case? I like that. Consistent with Gnome, which is a build option for XO. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
daniel wrote: On 22 January 2014 01:04, James Cameron qu...@laptop.org wrote: On Wed, Jan 22, 2014 at 12:41:04AM +0100, Daniel Narvaez wrote: I'm referring to this patch, I couldn't find it before. https://github.com/sugarlabs/sugar/pull/153 It's actually per network, not per device, so it only forgets present networks. Can you explain why we need to be able to forget non-present ones? To prevent a host from automatically connecting to a network that was previously available and connected to, but is not at the moment, due to distance or the network being off. This may be done because of a change of ownership of a host, or a change in the trust level of a network. Ok. The button is not really a good UI for that use case but it's probably something we don't want to regress. Is there any way at all to restore that security feature after removal the Discard network history button? Not that I can think of, other than nmcli. So... I think we need design input here. Would a history list with a forget button a la GNOME be a good way handle that use case? i've only seen the last few messages in this thread, so my comment may be off-base, but: i've always found the networkmanager UI to be sorely lacking. i often find that the network list has grown quite long, including things like linksys and netgear (i wonder where _those_ were?), and every starbucks or airport wifi i've visited in the last 6 months. to unclutter my UI involves at least 3 clicks per network (or maybe 4: scroll, select, delete, confirm). i've always wanted it to be a select all the networks you'd like to delete interface instead. part of the issue is that the remembered networks are remembered even if a previous connection attempt was unsuccessful. this means that clicking on open networks that aren't really open will grow the list, as will selecting a non-guest network by mistake. paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Rework the wireless control panel, section to respect non-wireless connections
Hi, I find it sometimes helpful when access points appear and disappear (or are at an extreme range). The network manager appears to get confused. As a further incantation, I also turn off the radio and turn it back on. So the 'discard' button has psychological advantages in working with a frustrating network environment. (Although in truth, the only real cure seems to be a cold start). Tony On 01/22/2014 01:41 AM, sugar-devel-requ...@lists.sugarlabs.org wrote: To: Daniel Narvaez dwnarv...@gmail.com Cc: Frederick Grose fgr...@gmail.com, sugar-devel@lists.sugarlabs.org sugar-devel@lists.sugarlabs.org Subject: Message-ID: 20140121233155.gg23...@us.netrek.org Content-Type: text/plain; charset=us-ascii On Wed, Jan 22, 2014 at 12:24:31AM +0100, Daniel Narvaez wrote: Before we go further discussing implementation, could someone explain why we need a global Discard wireless connections button vs the Forget item in the device palette which someone has mostly implemented already? Does Forget forget all networks, not just the ones present? Otherwise, the only reason I can think of is the installed base expectations and training issues. If I recall correctly, the main use case was inability to properly handle access points that either changed their passphrase or switched between encrypted and not-encrypted. If you add these test cases and pass them, I see no major problem with removing Discard ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
Fixes #4410 https://bugs.sugarlabs.org/ticket/4410 The 'Discard network history' button is peculiar to Sugar, and is destructive to all non-wireless connections, despite being in the 'Wireless' section of the control panel. In the proposed patch[0], the code variables and functions are renamed and coded to be specific to wireless connections. The 'Radio' checkbox instruction and 'Discard ...' button are reworded to avoid confusion over their state and actions.[1] If wireless hardware is not present on the system, the 'Wireless' section of the control panel is excluded.[2] [0,1,2] - https://github.com/sugarlabs/sugar/pull/228 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
Reviewed-by: James Cameron qu...@laptop.org Like it. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
On Mon, Jan 20, 2014 at 4:17 PM, Frederick Grose fgr...@gmail.com wrote: Fixes #4410 https://bugs.sugarlabs.org/ticket/4410 The 'Discard network history' button is peculiar to Sugar, and is destructive to all non-wireless connections, despite being in the 'Wireless' section of the control panel. In the proposed patch[0], the code variables and functions are renamed and coded to be specific to wireless connections. The 'Radio' checkbox instruction and 'Discard ...' button are reworded to avoid confusion over their state and actions.[1] If wireless hardware is not present on the system, the 'Wireless' section of the control panel is excluded.[2] [0,1,2] - https://github.com/sugarlabs/sugar/pull/228 Daniel Narvaez wrote via notificati...@github.com It seems like the code is handling adhoc networks specially, but I didn't find an explanation of that change. Can you please elaborate on it? The current code at, https://github.com/sugarlabs/sugar/blob/master/src/jarabe/model/network.py#L835 tests for sugar-internal connections by reading the connection_id string. The new code is specific to wireless connections. The first condition, the presence of a wifi_settings list, avoids 7 of the 7 sugar-internal connections on XO-1. The sugar ad hoc connections are avoided by a second condition, the same test as in the currrent code, connection_id.startswith(ADHOC_CONNECTION_ID_PREFIX). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
