• Thomas Haller's avatar
    settings: make NMSettingsPlugin a regular GObject instance and not an interface · 657b0714
    Thomas Haller authored
    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.
nm-settings-plugin.c 6.42 KB