Wifi Selection UI

[rmescandon]

Improved Look and feel of the available WIFIs list:

• Using vanilla framework theme
• Added feature to select an available network, provide a password, toggle show/hide that password and connect or cancel
• Updated README.md with needed steps for further development in this web UI

Known issues: After selecting a network, provide password and click to connect, no matter the result we won't receive any reply of the network connect operation result. This happens because that reply is async to the operation triggering.

• One solution could be having the user to refresh the UI
• Other solution could be requesting for the network state by polling and and show intermediate and final state.
• And other, maybe the better solution, could be using websockets to get connection changes from the backend side directly in the UI. (for this that would be maybe better having a React.js or other fw solution other than golang direct templates as we have so far, as things get complicated...)

No matter which solution is taken, for this to work properly it is needed including in netman package operation to know current status of the different interfaces, so that the list of available ones can be shown in different colors depending on their current status, and also having signals when certain interface changes its status.

from /org/freedesktop/NetworkManager/Devices/ in system dbus it is possible request property org.freedesktop.NetworkManager.Device.State which would return its current state (https://developer.gnome.org/NetworkManager/unstable/nm-dbus-types.html#NMDeviceState). The ones we are at least interested are: NM_DEVICE_STATE_DISCONNECTED = 30 NM_DEVICE_STATE_CONFIG = 50 NM_DEVICE_STATE_ACTIVATED = 100

that would be set respectively to disconnected, connecting and connected in the UI.

All this can be implemented in another PR. (I think)

[knitzsche]

Hi Robert. Regarding the issue you describe, it is not expected that the user will be able see the response to the connection request because connecting to the new external AP also involves first bringing down the current wifi-ap through which the user is connected to the portal. This is because (for version 1 anyway), it is not expected that we can simultaneously have the wifi-ap UP and connected to the user and connect to an external AP through the sam single wifi card.

[knitzsche]

Indeed, the portal should have some text that informs the user that their current connection will be lost (when they click OK) and they should try to reconnect to the device over the new AP connection after a minute or so. (Whether they will connect via the new IP address (which they would need to get from their AP I presume) or via avahi (which we need to look into) is an open question.)

[rmescandon]

Ah true. You are right. I need then to remove some not needed network status stuff and also add that inform text when pressed connect button. I'll let you know when ready again to review

[rmescandon]

Ready to re-review