network: add network integration with NetworkManager backend #96
Conversation
|
Why are we linking nm? Should be entirely over dbus |
This reverts commit 8679f79.
NMWireless will be a property of Device (if DeviceType==Wifi). In the future if many org.freedesktop.networkmanager.Device.* are implemented, we can use the factory pattern to create an NMDevice with its subdevice properties and methods.
|
I'm not sure what stage of development you're at here and haven't checked code yet, but just so we're clear I'd like to expose this under I don't think I've made that clear so far. (If you've got any questions, @ me here or in the matrix/discord) |
outfoxxed
force-pushed
the
master
branch
2 times, most recently
from
9d41148 to
4b35d7b
Compare
cpwrs
changed the title
outfoxxed
force-pushed
the
master
branch
2 times, most recently
from
525a933 to
bb206e3
Compare
There was a problem hiding this comment.
Sorry its taken so long but here's an initial review.
I'd appreciate if auto was used in more places, as well as whitespace following the existing code-style more as well.
There are a couple bits in here that look completely insane, but judging by the fact that they're on the NM api surface I'm going to assume it's NM's fault.
- Prefer bindables over connections for synced properties - Remove lambdas from ready and disappeared signal connections - Add namespaces to Q_PROPERTY definitions - Remove Network.wifi.defaultDevice (easy to add in userspace) - Add all devices to a ListView in network.qml
|
@outfoxxed Thanks for the feedback! I think this is ready for another review.
Yep. Unfortunately the api doesn't have any concept of wifi networks. Had to grab access points from one interface, "active" and "saved" connections from another, and then group them by SSID. It also doesn't give any useful security info, hence the copied code from nmcli. Other clients do something similar: |
cpwrs
changed the title
cpwrs
changed the title
outfoxxed
force-pushed
the
master
branch
3 times, most recently
from
a92879d to
9bb2c04
Compare
|
@bbedward Would love your feedback on this API. Besides the obvious missing features, does the design make anything difficult for DMS? |
It looks pretty consistent with quickshell conventions to me. I'd like to see the agent/connection manager, but it's not necessary for the initial integration IMO (the bluez implementation doesn't have an agent either) |
|
Resolved all but scan |
A few changes to the frontend Network API: - Expose all devices at the toplevel - Move wifi rfkill options to the toplevel - Add WifiSecurityType (backend agnostic) - Move WifiNetwork signal strength to a qreal from 0.0 to 1.0 - Add extensible BaseNetwork class
|
Made an attempt at WifiScanner following the KDE implementation. Requires deprecated header |
- Add WifiScanner to replace requestScan in API - Implement NM scanner that avoids rate limit - Add conditional visibility to networks based on scanner state - Add gates to backend-specific props in the manual test
|
I think it's more useful to expose each available connection like KDE, networks are more of a connection variant. Gonna make that change and set up the API to be extensible to other wifi device modes (station, ap, adhoc) and their associated connections (networks, hotspots, peers) |
4 participants
Adds basic support for listing wifi devices and networks and attempting a connection. Missing support for connections that require an agent.
Closes #74.