ironbar
ironbar copied to clipboard
JakeStanger
Network Manager module
Is your feature request related to a problem? Please describe. Currently this is missing functionality that has to be scripted.
Describe the solution you'd like
A new module for managing network connections that connects to the NetworkManager service. This should primarily focus on WiFi connections, but Ethernet and VPN connections are also on the table.
Describe alternatives you've considered The custom module can currently be used to achieve basic functionality but this is sub-par.
Additional context Crate that looks hopeful for this: https://crates.io/crates/network-manager
Problem is all the network manager bindings I could find use the dbus crate, and not zbus :/
How much of a problem is that? Obviously pure rust is better and I'd rather avoid bringing even more deps into the mix, but if it works it works right?
How much of a problem is that? Obviously pure rust is better and I'd rather avoid bringing even more deps into the mix, but if it works it works right?
I'm pretty sure the dbus crate doesn't support async
Not ideal, but that's okay - you can use tokio's spawn_blocking to delegate it to its own task and avoid blocking the main thread
Thats true, also seems https://crates.io/crates/network-manager is only updated on the github, and not on crates.io
Mm yeah didn't spot that. Looks like they've been working towards libnm-rs which suffers from the same thing, and has a lot of git dependencies.
I guess that isn't a complete blocker, but I'd like to try and resolve that before this can be called complete.
Forking libnm is also a possibility, seems to only use git deps because of glib, maybe a libnm-ironbar package could be published
Is using zbus on its own hard?
From my (little) experience, it's not easy but it's not too bad. It depends a bit on the interface, but is certainly nicer than working with Wayland protocols.
Forking libnm is also a possibility
Not against it. I'd rather not have to maintain another library myself if I don't have to but as a last resort, sure.
I noticed that you're already using Gio, Gio also has decent dbus support with async if you want to write something from scratch.
Hey @zedfrigg I've seen you've been working on a NM module in your own fork. Do you have plans to merge that into the upstream? If not, can I take that as the basis for the upstream implementation? Cheers
Yes I am planning to upstream it! It does need some more work first as it doesn't handle all connection types well (e.g. VPNs), but I will continue working on it when I have the time.
Awesome! In that case I'll assign this issue to you. That's a big undertaking so I really appreciate it. Let me know if you need a hand, or if you're tight on time and want me to take over.
I unfortunately have not had the time yet to work on this further. What may be a good idea however is to upstream what I have now, and then an improved version later.
The module is functional in its current state, the icon displayed directly corresponds to the PrimaryConnectionType property of the NetworkManager DBus API. The drawback of this is that for example if you have an active VPN connection, it is reported as the primary connection, and you have no way of knowing whether you're for example connected to a wifi network. Because of this I'm planning to rewrite this module to look at the different active connections directly, and display multiple icons for wifi, cellular, VPNs, etcetera (like e.g. Gnome or Android). Unfortunately the logic for this is non-trivial, so it will take some more time.
All this brings me to a question for @JakeStanger: would you be okay with me upstreaming this over multiple PRs, one now for the minimal functionality, and more later?
Yes, it sounds like it's in a good enough state that we can look into merging what's there and then work on improvements. We can just open an issue for the VPN bits or leave this open, and/or a note in the docs.
It'll be a while before the next release goes out so we'll have time to test, fix, tweak etc before I'd consider it stable anyway.
The module just displays connection state at the moment and doesn't provide control (ie ability to connect to network etc) right?
Great, I added a note in the module docs explaining this.
And yeah, that's correct. It's pretty bare bones at the moment, it's literally just an icon for the network state, it can't even tell you what what SSID you're connected to for example. I looked into adding this, but until the aforementioned refactor is done it'd just be a hack (see here for the details) and I'd rather not invent a square wheel first and then a round one later.
Let me know if that's acceptable. In the meantime I've opened a PR for merging what we have now.
I think something is better than nothing at this stage, so long as it works reliably.
It will be worth brainstorming a roadmap of sorts for this to make sure further updates stay on track and there's a finished module in site. Let me know your thoughts on that.
@JakeStanger should this issue be closed now, or will we use it to track enhancements to the NM module?
I think we use it to track progress, as this isn't where I'd want it to be to consider it a complete module.
I'd like to see the module make nm-applet redundant, but I'd consider the following must-haves above all else:
- Better network connectivity status info (wifi strength etc)
- Ability to connect to WiFi networks
For the record, I have at least implemented WiFi Strength and icon configuration on this PR https://github.com/Zedfrigg/ironbar/pull/1, on top of another branch by @JakeStanger.
