mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
synced 2026-01-09 10:00:22 +01:00
657b0714b8
NMSettingsPlugin was a glib interface, not a regular GObject instance. Accordingly, settings plugins would implement this interface instead of subclassing a parent type. Refactor the code, and make NMSettingsPlugin a GObject type. Plugins are now required to subclass this type. Glib interfaces are more cumbersome than helpful. At least, unless there is a good reason for using them. Our settings plugins are all internal API and are entirely under our control. It also means, this change is fine, as there are no implementations outside of this source tree. Using interfaces do would allow more flexibility in implementing the settings plugin. For example, the plugin would be able to derive from any other GObject type, like NMKimchiRefrigerator. But why would we even? Let's not add monster classes that implement house appliances beside NMSettingsPluginInterface. The settings plugin should have one purpose only: being a settings plugin. Hence, requiring it to subclass NMSettingsPlugin is more than resonable. We don't need interfaces for this. Now that NMSettingsPlugin is a regular object instance, it may also have state, and potentially could provide common functionality for the plugin implementation -- if that turns out to be useful. Arguably, an interface can have state too, for example by attaching the state somewhere else (like NMConnection does). But let's just say no. On a minor note, this also avoids some tiny overhead that comes with glib interfaces. |
||
|---|---|---|
| .. | ||
| tests | ||
| nms-keyfile-connection.c | ||
| nms-keyfile-connection.h | ||
| nms-keyfile-plugin.c | ||
| nms-keyfile-plugin.h | ||
| nms-keyfile-reader.c | ||
| nms-keyfile-reader.h | ||
| nms-keyfile-utils.c | ||
| nms-keyfile-utils.h | ||
| nms-keyfile-writer.c | ||
| nms-keyfile-writer.h | ||