-
Thomas Haller authored
We have certain artificial properties that not only depend on one property alone or that depend on a property in another(!) setting. For that, we have synth_func. Other than that, synth_func and get_func are really fundamentally similar and should be merged. That is because the distinction whether a property value is "synthetized" or just based on a plain property is minor. It's better to have the general concept of "convert property to GVariant" in one form only. Note that compare_property() is by default implemented based on get_func. Hence, if get_func and synth_func get merged, compare_property() will also require access to the NMConnection. Also it makes some sense: some properties are artificial and actually stored in "another" setting of the connection. But still, the property descriptor for the property is in this setting. The example is the "bond.interface-name" which only exists on D-Bus. It's stored as "connection.interface-name". I don't really like to say "exists on D-Bus only". It's still a valid property, despite in NMSetting it's stored somehow differently (or not at all). So, this is also just a regular property for which we have a property-info vtable. Does it make sense to compare such properties? Maybe. But the point is that compare_property() function needs sometimes access to the entire connection. So add the argument.
b1344b6b