This was deferred, pending information on the non-breakage of other NetworkManager applets as part of this feature.

Dan, would you be able to either clarify in this ticket or attend the next FESCo meeting on Friday?

The external NM API should stay almost exactly the same. There will be additional API to allow things like scanning for providers, setting the PIN, etc, but the existing D-Bus interface of NetworkManager (and thus how any applet, not just nm-applet, woudl talk to NM) should stay the same.

However, those applets may require changes to handle the conversion to udev instead of HAL, depending on how they were using NetworkManager before. So they'll ahve to change anyway, and we'll have to make sure we coordinate with the KDE guys at least on that.

Network management is handled by a separate component of Solid, so I don't think this is deeply intertwined with HAL, but I'm not sure about the relationship between HAL and NM in the first place. Is NM exporting some HAL-related stuff in the API?

NM provided the HAL UDI of the device in a property of the D-Bus interface, which applets may have relied on to query HAL for further information about the device. For example, nm-applet used it to pull the device descriptions out of HAL (so users would see something like "Intel Gigabit Ethernet" instead of "Network card"). That property still exists, but is now the sysfs path of the device; so it's not a hard API break, but could cause some issues if the client isn't aware that HAL is no longer being used.

What's the exact name of the property (so we can grep the NM users for it)?

"Udi"

This feature is accpeted