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.
The virtual function init() naturally leads to calling the wrapper
function nm_settings_plugin_init(). However, such ${TYPE}_init() functions
are generated by G_DEFINE_TYPE().
Rename to avoid the naming conflict, which will matter next, when the
interface will be converted to a regular GObject class.
Note that while these are settings plugin, there is no public
or stable API which we need to preserve.
- All internal source files (except "examples", which are not internal)
should include "config.h" first. As also all internal source
files should include "nm-default.h", let "config.h" be included
by "nm-default.h" and include "nm-default.h" as first in every
source file.
We already wanted to include "nm-default.h" before other headers
because it might contains some fixes (like "nm-glib.h" compatibility)
that is required first.
- After including "nm-default.h", we optinally allow for including the
corresponding header file for the source file at hand. The idea
is to ensure that each header file is self contained.
- Don't include "config.h" or "nm-default.h" in any header file
(except "nm-sd-adapt.h"). Public headers anyway must not include
these headers, and internal headers are never included after
"nm-default.h", as of the first previous point.
- Include all internal headers with quotes instead of angle brackets.
In practice it doesn't matter, because in our public headers we must
include other headers with angle brackets. As we use our public
headers also to compile our interal source files, effectively the
result must be the same. Still do it for consistency.
- Except for <config.h> itself. Include it with angle brackets as suggested by
https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
A GObject interface, like a class, has two different C types
associated with it; the type of the "class" struct (eg, GObjectClass,
GFileIface), and the type of instances of that class/interface (eg,
GObject, GFile).
NetworkManager was doing this wrong though, and using the same C type
to point to both the interface's class struct and to instances of the
interface. This ends up not actually breaking anything, since for
interface types, the instance type is a non-dereferenceable dummy type
anyway. But it's wrong, since if, eg, NMDeviceFactory is a struct type
containing members "start", "device_added", etc, then you should not
be using an NMDeviceFactory* to point to an object that does not
contain those members.
Fix this by splitting NMDeviceFactory into NMDeviceFactoryInterface
and NMDeviceFactory; by splitting NMConnectionProvider into
NMConnectionProviderInterface and NMConnectionProvider; and by
splitting NMSettingsPlugin into NMSettingsPluginInterface and
NMSettingsPlugin; and then use the right types in the right places.
As a bonus, this also lets us now use G_DEFINE_INTERFACE.
Since there have not been separate system and user settings services
since 0.8, the "system" in NMSystemConfigInterface is kind of
meaningless. Rename it to NMSettingsPlugin, which describes what it
does better.
This is just:
git mv src/settings/nm-system-config-interface.h src/settings/nm-settings-plugin.h
git mv src/settings/nm-system-config-interface.c src/settings/nm-settings-plugin.c
perl -pi -e 's/SystemConfigInterface/SettingsPlugin/g;' \
-e 's/system_config_interface/settings_plugin/g;' \
-e 's/system-config-interface/settings-plugin/g;' \
-e 's/SYSTEM_CONFIG_INTERFACE/SETTINGS_PLUGIN/g;' \
-e 's/sc_plugin/settings_plugin/g;' \
-e 's/SC_PLUGIN/SETTINGS_PLUGIN/g;' \
-e 's/SC_IS_PLUGIN/SETTINGS_IS_PLUGIN/g;' \
-e 's/SC_TYPE_PLUGIN/SETTINGS_TYPE_PLUGIN/g;' \
-e 's/SCPlugin/SettingsPlugin/g;' \
-e 's/nm_system_config_factory/nm_settings_plugin_factory/g;' \
$(find src/settings -type f)
(followed by some whitespace fixups in nm-settings-plugin.c, and a
Makefile.am fix for the rename)
