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
- 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) |
outfoxxed
left a comment
outfoxxed
left a comment
There was a problem hiding this comment.
Sorry I wasn't able to do a full review today, but I think I got most of the interface. These changes don't necessarily have to be made if you've got a good reason not to though.
|
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
- Add WifiDeviceMode and WifiDevice.mode - Add module.md - Reimplement NMWirelessNetwork - Fix mode checking for NMWirelessDevice onConnectionLoaded/onAccessPointLoaded - Move security type to bindings in NMAccessPoint and NMConnectionSettings
|
Sorry I haven't looked at this recently, is it ready for review again? |
|
@outfoxxed Yep! I decided to keep WifiNetwork as a group of all access points and connection settings for a given SSID. KDE shows a network item PER conn settings, which makes sense because its only backend (NM) is connection centric. But I think 99% of use is connecting to a network which only has one conn settings. IWD doesn't even allow multiple. Right now, if theres multiple it attempts a connection using the best settings (highest security). Eventually we'd want to expose the AccessPoint(s) and ConnSetting(s) (only one for IWD) under these networks and expand the connect() function to optionally take a specific AP or settings. This gives feature parity with the NM API for the 1% who actually use multiple settings. A connection editor and these extensions to WifiNetwork would be a large feature so I was hoping to get the basics merged before that. The biggest issue with not including ConnSetting initially is losing a forget() function that removes the setting. Does a forget() at the WifiNetwork level that deletes ALL its associated settings suffice for now? |
| ///! Scans for available wifi networks. | ||
| /// When enabled, the scanner populates its respective WifiDevice with an active list of available WifiNetworks. | ||
| class WifiScanner: public QObject { | ||
| Q_OBJECT; | ||
| QML_ELEMENT; | ||
| QML_UNCREATABLE("Scanner can only be acquired through WifiDevice"); | ||
|
|
||
| // clang-format off | ||
| /// True when currently scanning for networks. | ||
| Q_PROPERTY(bool enabled READ enabled WRITE setEnabled NOTIFY enabledChanged BINDABLE bindableEnabled); | ||
| // clang-format on | ||
|
|
||
| public: | ||
| explicit WifiScanner(QObject* parent = nullptr); | ||
|
|
||
| QBindable<bool> bindableEnabled() { return &this->bEnabled; }; | ||
| [[nodiscard]] bool enabled() const { return this->bEnabled; }; | ||
| void setEnabled(bool enabled); | ||
|
|
||
| signals: | ||
| void enabledChanged(bool enabled); | ||
|
|
||
| private: | ||
| Q_OBJECT_BINDABLE_PROPERTY(WifiScanner, bool, bEnabled, &WifiScanner::enabledChanged); | ||
| }; |
There was a problem hiding this comment.
This can reduce to a bool property unless there's more functionality to add?
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.