Albert Plugin: Wi-Fi

[ManuelSchneid3r]

Discussed in https://github.com/orgs/albertlauncher/discussions/1484

^{Originally posted by HarshNarayanJha November 23, 2024}
A new plugin for albert. Wi-Fi connection manager
(for NetworkManager and nmcli setups).

This Plugin lets you connect to (or disconnect from) any known wireless network quickly. It can also scan for new connections and connect to them. I needed a quick Wi-Fi switching solution, so I made this. Hope someone finds this useful too.

The trigger is wifi, typing this would show a list of wifi connections (as shows by nmcli connection show). Primary action is to connect/disconnect the network. Holding alt lets you scan for new networks. I am planning to add Ethernet connections too for ethernet people, but I couldn't figure out if I should change the trigger keyword or do something else for ethernet.

APs and be listed and connected to by typing wifi ls.

Screenshot:

GitHub & Installation: https://github.com/HarshNarayanJha/albert_wifi

[martinengelke]

Would love that feature. Your bluetooth plugin is one of my daily companions :)

I mean, basically I could not live without Albert anymore haha ^^

[ManuelSchneid3r]

I wonder if it makes more sense to have plugins grouped conceptually or rather technically. I mean there are some concepts that are backed by the same libraries/interfaces like eg VPN and Wifi. Both backed by network manager on most platforms.

[martinengelke]

Sounds like it's manageable? I like that you type bt and wifi. I would not like to have a network trigger and all the settings at one place. I am fine to divide my tasks. That's why I prefer a launcher over a dashboard. I don't like to be aware of everything at every time. It's hard to focus nowadays anyway.

[HarshNarayanJha]

One trigger to handle all bluetooth, vpn and wifi (or maybe wired networks in future) is clearly not manageable. It is good to have different keywords.

The thing that could work is to have multiple triggers for a single plugin, then we can group all of them under a Network plugin, and have different triggers do their job.

Also, @ManuelSchneid3r I think you mentioned that you are working on Async List Tiles (Items). That's a good opportunity to have live signal strengths, status, and scanning results for this plugin

[ManuelSchneid3r]

It is possible to register multiple handlers per plugin. But it does not make much sense to do so imho. Technically the backends may have different apis. So we could end up loading libraries a user does not even use. Users will complain about that. Then a solution would be to offer checkboxes inside the plugin and to load libraries lazy. This resembles the purpose of the general plugin system inside a plugin. Too much of a hassle for no gain. Further I think from the UX point of view having a plugin per intent is more easy to grasp than having to find this feature buried inside the plugin settings.

[ManuelSchneid3r]

Also I agree one trigger for different intents is rather confusing.

The dynamic item is a thing I really want to address soon. However the async handler is wip and its api design is tough, especially since it also affects the python api.

[ManuelSchneid3r]

I wrote a prototype for macos. Its tough though due to the security permissions. I put it aside for now since it takes a lot of time and there is other stuff to do.

[HarshNarayanJha]

Anyone who can test this branch?

[martinengelke]

If somebody could compile it for me? :)

[Iss-in]

@martinengelke sorry for off topic comment, but that bluetooth plugin is missing from plugin list in app. Also iirc albert a list of many unofficial plugins, but now i cant find it anywhere
can you share its link

[ManuelSchneid3r]

@Iss-in The Bluetooth plugin is not yet implemented on Linux. I'd be glad to pull PRs. You could probably copy the mpris plugin which does a lot of the dbus stuff and adjust the dbus interface.

[ManuelSchneid3r]

Anyone who can test this branch?

Which branch?