PPPoE connections involve two different network connections, making it
ambiguous what the "Device" field refers to. Clarify that it refers to
the Ethernet device, not the PPP device.
NMActiveConnection:connection was an object path rather than an
NMRemoteConnection because in the past the NMObject property system
wasn't capable of handling NMRemoteConnection-valued properties.
NMActiveConnection:master was an object path rather than an NMDevice
entirely by accident. Fix both.
NMActiveConnection:specific-object can't currently be converted to an
object, because we don't know ahead of time what object type it is,
and NMObject can't deal with that. Instead, we rename it to
:specific-object-path (and likewise for its get function), both to
emphasize that it doesn't behave like other properties, and to leave
the old name open for an actual object-valued property later on.
If a master is deleted but its slaves are left behind, show those
slaves in the appropriate part of the connection list, so they can be
deleted. (This code is just copied from nm-connection-editor.)
nmt_newt_grid_size_allocate() depends on nmt_newt_grid_size_request()
having been called immediately prior, which would normally be true,
except that NmtNewtSection adjusts the label widgets in its border to
match its allocation, so when its size changes, it will end up calling
size_allocate() on the border with out-of-date requisition data. Fix
that by re-size_requesting the border after modifying it.
https://bugzilla.gnome.org/show_bug.cgi?id=738010
NMSettingSerial:parity was defined as a char-typed property that could
have the (case-sensitive!) values 'n', 'E', or 'o'. This is zany. Add
an NMSettingSerialParity enum, and use that instead.
Add nm_utils_wifi_strength_bars(), which figures out whether the
terminal can display graphical wifi strength bars, and converts a
numerical value to the appropriate Unicode or ASCII characters.
This also now takes into consideration the fact that the console font
doesn't contain all of the necessary characters, so we can't display
the graphical bars there. (rh #1131491)
Use g_print() and g_printerr(), which wrap printf() and
fprintf(stderr,...), but handle conversion from UTF-8 if the locale is
using a different character set.
Make synchronous APIs take GCancellables, and make asynchronous APIs
use GAsyncReadyCallbacks and have names ending in "_async", with
"_finish" functions to retrieve the results.
Also, make nm_client_activate_connection_finish(),
nm_client_add_and_activate_finish(), and
nm_remote_settings_add_connection_finish() be (transfer full) rather
than (transfer none), because the refcounting semantics become
slightly confusing in some edge cases otherwise.
Merge nm_remote_settings_add_connection() and
nm_remote_settings_add_connection_unsaved(), and likewise
nm_remote_connection_commit_changes() and
nm_remote_connection_commit_changes_unsaved(), by adding a boolean
flag to each saying whether to save to disk.
The entry can't be empty. Otherwise removing the value and saving connection
would result in the primary option containing only the first character of the
original value.
Check whether NM is running before comparing nmcli and NM versions. Returning
NMC_RESULT_ERROR_NM_NOT_RUNNING is in accordance with other nmcli commands.
Applies to status commands such as "nmcli radio" or "nmcli g status".
This is consistent with other commands.
The "RUNNING" field is now always "running", the tool will just return
an error instead of setting it to "not running". It never signalled
whether the daemon was actually running anyway, only whether the client
managed to connect to it.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Port libnm-core/libnm to GDBus.
The NetworkManager daemon continues to use dbus-glib; the
previously-added connection hash/variant conversion methods are now
moved to NetworkManagerUtils (along with a few other utilities that
are now only needed by the daemon code).
In preparation for porting to GDBus, make nm_connection_to_dbus(),
etc, represent connections as GVariants of type 'a{sa{sv}}' rather
than as GHashTables-of-GHashTables-of-GValues.
This means we're constantly converting back and forth internally, but
this is just a stepping stone on the way to the full GDBus port, and
all of that code will go away again later.
libnm-util's connection deserializing/copying/replacing functions have
odd semantics where sometimes they both modify a connection AND return
an error. libnm-core tried to improve things by guaranteeing that the
connection would not be modified if the new settings were invalid, but
this ended up breaking a bunch of places that needed to be able to
work with invalid connections. So re-fix the functions by reverting
back to the old semantics, but having return values that clearly
distinguish whether the connection was modified or not.
For comparison:
- nm_connection_new_from_hash() / nm_simple_connection_new_from_dbus():
- libnm-util: returns a valid connection or NULL.
- OLD libnm-core: returned a valid connection or NULL.
- NEW libnm-core: returns a valid connection or NULL.
- nm_connection_duplicate() / nm_simple_connection_new_clone():
- libnm-util: always succeeds, whether or not the connection is
valid.
- OLD libnm-core: returned a valid connection or NULL
- NEW libnm-core: always succeeds, whether or not the connection
is valid.
- nm_connection_replace_settings_from_connection():
- libnm-util: always replaces the settings, but returns FALSE if
the connection is now invalid.
- OLD libnm-core: either replaced the settings and returned TRUE
(if the settings were valid), or else left the connection
unchanged and returned FALSE (if not).
- NEW libnm-core: always replaces the settings, and has no
return value. (The modified connection is valid if and only if
the replaced-from connection was valid; just like with the
libnm-util version.)
- nm_connection_replace_settings():
- libnm-util: returns TRUE if the new settings are valid, or
FALSE if either (a) the new settings could not be deserialized
and the connection is unchanged, or (b) the new settings were
deserialized, and the connection was updated, but is now not
valid.
- OLD libnm-core: either replaced the settings and returned TRUE
(if the settings were valid), or else left the connection
unchanged and returned FALSE (if not).
- NEW libnm-core: returns TRUE if the connection was updated
(whether or not it is valid), or FALSE if the new settings
could not be deserialized and the connection is unchanged.
