We shall not only have a PropertyInfo. Most properties share common
behavior, that is, they have a type. Move the function pointers to
a NmcPropertyType structure, so that it can be reused for multiple
properties.
This promotes the idea that properties have a (limited) set of types
with some type specific behaviors. Contrary, to having each property
re-implement fully it's type. E.g. instead of having various property
re-define their full behavior as an "bool", have one property type
"bool" which can be attached to a property.
Add an improved way of tracking meta data about settings.
E.g. it is wrong to generate for each property a nmc_property_*_get_*()
function. Instead, there should be a meta data about the property
itself, and a mechanism to retrieve the property.
For now, only do this for NMSettingConnection and keep all the existing
infrastructure in place. Later on all settings shall be moved.
Especially to accomodate NmcOutputField mangles the concept of
setting-meta data, formatting options, and collecting output results.
It's a total hack, that will be need fixing later.
This will be solved differently by th/setting-user-data-bgo776276
branch. Revert the change for now, the same functionality will be
restored later.
This reverts commit 623d888801.
Don't print value output in the "PRETTY" format when the --terse option
has been specified.
This should allow to feed back the output from "nmcli show" to "nmcli
modify" without changes.
We can't pass the password obtained from
nm_setting_802_1x_get_*private_key_password() to
nm_setting_802_1x_set_*private_key() as the latter also frees the old
password.
Fixes: afd2811028
* all getter/setter/describe, ... functions grouped according to properties
* sort the settings groups alphabetically
(cherry picked from commit 418733f2c1)
It results in a rather confusing behavior:
# nmcli c modify wifi \
802-1x.private-key /etc/pki/themostsecret.key \
802-1x.private-key-password verystrong
Error: failed to modify 802-1x.private-key: private key
password not provided.
Moreover, the user might have a good reason for not specifying it on a command
liue and it's not strictly required anyway -- we'll do fine if we don't verify
a private key at addition time.
We now require settings-docs.c to be present. Either, configure
with --enable-gtk-doc to have it build, or use the pre-generated file
from the source tarball.