[Sugar-devel] [DESIGN] NetworkManager / Neighborhood design changes

[Gary Martin]

On 5 Jun 2011, at 15:14, Sascha Silbe wrote:

> Porting Sugar to the NetworkManager 0.9 API and enabling new use cases (including connecting to networks with hidden SSIDs) requires some design changes in both the Neighborhood and the Frame. To get everyone on the same page, I will first give an overview of the NetworkManager API and list the (new) requirements. The suggested design changes and open questions will be discussed in detail during the upcoming Design Team meeting.
> 
> NM 0.9 API
> 
> Types of objects:
> 
> 	• Devices: Wired, Wireless, Modem, Bluetooth (DUN/PAN), OlpcMesh, WiMax
> 	• Access Points (Wireless), NSPs (WiMax)
> 	• Settings
> 	• Active Connections
> 	• VPN Connections
> 	• VPN Plugins
> Activating a connection requires:
> 
> 	• a connection (setting?)
> 	• a device (except for VPN)
> 	• for wifi: access point (can be chosen automatically)
> 	• for VPN: path of active connection ("base" connection)
> Global states:
> 
> 	• unknown
> 	• no connectivity (asleep, disconnected, disconnecting)
> 	• local, site, global connectivity
> Devices can be disconnected; no further automatic connection activation will happen for this specific device.
> 
> VPN connections can be disconnected, regular connections can be deactivated.
> 
> Wifi connections can be restricted to a single BSSID (expose in key dialog?)
> 
> Networking can be globally en/disabled both totally and for classes of hardware (wifi, wwan=GSM/3G, wimax).
> 
> Requirements
> 
> 	• Ability to activate a specific connection if multiple connections are available for a device / access point
> 	• Ability to prevent automatic reconnections for a device (either via using the Disconnect() call for the device or disabling the entire hardware class); preferably happens by default
> 	• Easy access to powering down a device class
> 	• Ability to restrict a connection to a single AP (BSSID)
> Nice to have
> 
> 	• Ability to add a new connection for a device / AP that already has a configured connection
> Suggested design changes
> 
> 	• AP palette (Neighborhood):
> 		• If there's more than one connection, list all of them. Selecting the connection activates it.
> 		• If there's at least one connection, show option "Add another connection"
> 	• Wireless device palette (Frame):
> 		• New option "Connect to hidden network". Once the connection has been successfully configured, the AP should turn up as usual in the Neighborhood whenever it is in range (AFAIK at least).
> 		• New option "Disable all wireless devices" resp. "Enable wireless devices" (wording could do with some improvement). If there is more than one wireless device, all of them will show the option and all of them will be powered down / up when the option is selected.
> 	• "GSM" = Modem device palette (Frame):
> 		• Behave like the new AP palette: list of connections, "Add another connection"
> 		• New option to disable / enable WWAN devices, like for the wireless device palette
> 	• Wired device palette (Frame):
> 		• Analogous to GSM device, but no way to en/disable all wired devices (not supported by NM)
> Potential additions
> 
> If we have enough time to implement these, we could add support for:
> 
> 	• Bluetooth (DUN/PAN)
> 		• probably similar to modems ("GSM")
> 	• WiMax
> 		• probably similar to wireless
> 	• VPN Connections
> 		• would appear in the palette for any device that currently has an active connection
> 		• no support for adding new VPN connections yet
> Open questions
> 
> 	• Should we continue to show the "Connect" option for APs if there's at most one connection configured or should we always show a list of connections? Rename "Add another connection" to "Add connection" if there's no connection configured yet?
> 	• How do we distinguish the different connections in the list? User-chosen name? Add a way to change the name later?
> 	• How do we let the user configure the connection? The current globally modal keyphrase dialog is a major usability disaster.
> 	• Differentiated connectivity indicators (need to investigate work done by Peter Robinson and review previous design discussion)

I just wanted to follow up with a link to some discussion I had with Sascha on Sunday trying to clarify some of his points and goals regarding his NetworkManager efforts, the design meeting logs are at:

	http://meeting.sugarlabs.org/sugar-meeting/meetings/2011-06-05T16:17:34

A quick summary of what was covered is not so easy, other than that there were no solid design decisions made (it was only Sascha and myself at the meeting). This work will be a rather major undertaking to get right – I don't want to see the Neighbourhood UI's 'low floor' eroded for what seems might be fairly rare edge case requirements. So, there will be plenty of tough design choices needed to move this forward.

One path that seems worth following up on is one Eben talked of a number of times – allow palette menu items to directly link and raise CP (Settings) module dialogues. Some of the additional complexity can then be placed in new/modified CP modules rather than ballooning palettes with new options. Example: a module that allows editing/managing wireless AP credentials could finally be the sugarised replacement for the Network Manager pop-up dialogue we currently get, but would also allow us to expose extra options for some of the use case Sascha is trying to get at (pre-filled or hidden where possible for the common cases). The same module could be used to enter details of SSID hidden networks.

Lot's to think about, and I certainly don't have a clear picture in my mind yet. Sascha is going to try and pull together a wiki page with screen shots of all the current related dialogues (will need some help with the GSM modem device as neither of us have access to a device), this should help get everyone on the same page with regard to where we are now – and then perhaps start to experiment with some UI mockups and see what might stick.

Regards,
--Gary

> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel