Scope for plasma-nm
plasma-nm is absolutely massive, both in terms of code size (about 40K LOC) and functionality it provides. Now being large is not a problem in itself, but it can become problematic if it leaks into the UX and affects maintainability of the code.
In my non-scientific experience users expect a few things from a network management UI:
- Connect to a Wifi network, both simple password-protected networks and corporate/university networks (WPA Enterprise)
- Connect to their work/university/streaming/whatever VPN
- Make their laptop/USB modem work (e.g. enter then PIN)
- Turn Wifi/Airplane mode on/off
- Do basic troubleshooting when things don't work
However the KCM also provides a number of things on top of that:
- Creating a wide variety of connections types (e.g. Infiniband, Bond, Bridge, Team, VLAN)
- Fine-grained editing of existing connections with all kinds of technical details
The KCM more or less exposes the full capabilities of NetworkManager.
This raises the question: Is all of that even necessary? Is anyone going to use the KCM to configure a VLAN? Or a Team (I don't even know what that is)?
This wide scope of the KCM results in UX problems like the one described in #3, where the useful connection options are drowned in a list of semi- or not-at-all useful options.
It also makes it very hard to evolve the codebase. Currently the KCM is a hybrid of Widgets and QML, and attempts to fully port it to QML are stalled because of the massive scope.
I propose that we think very hard about what we actually want to achieve with this KCM and whether our current conceptual approach is suitable for that.
In particular I'd argue that plasma-nm does not need to expose the full feature set and complexity of NetworkManager and we should instead leave that to projects like network-manager-applet