This change (improves) behavior.
Before, we would only complete
if (g_strcmp0 (con_type, nmc_tab_completion.con_type) != 0)
which doesn't really make sense as it depends on the slave-type,
not nmc_tab_completion.con_type.
- have the "self" argument first, before the environment arguments.
It's more idiomatic.
- from within cli, always pass nmc_meta_environment and nmc_meta_arg
where needed.
- drop the union in NMMetaAbstractInfo. I was suppost to make casts
nicer, but it doesn't really.
When generating output data, nmcli iterates over a list of
property-descriptors (nmc_fields_ip4_config), creates an intermediate
array (output_data) and finally prints it.
However, previously both the meta data (nmc_fields_ip4_config) and
the intermediate format use the same type NmcOutputField. This means,
certain fields are relevant to describe a property, and other fields
are output/formatting fields.
Split this up. Now, the meta data is tracked in form of an NMMetaAbstractInfo
lists. This separates the information about properties from intermediate steps
during creation of the output.
Note that currently functions like print_ip4_config() still have all the
knowledge about how to generate the output. That is wrong, instead, the
meta data (NMMetaAbstractInfo) should describe how to create the output
and then all those functions could be replaced. This means, later we want
to add more knowledge to the NMMetaAbstractInfo, so it is important to
keep them separate from NmcOutputField.
Embed a @meta_type structure in NMMetaSettingInfoEditor and
NMMetaPropertyInfo. This allows to make the NMMeta*Info instances
themself to become generic and they can be passed around as generic
NMMetaAbstractInfo types.
For one, the embedded NMMetaType pointer can be used to determine
of which type a NMMetaAbstractInfo instance is. On the other hand,
the NMMetaType struct can be extended to be a VTable to provide
generic access to the type.
In the end, both NMMetaSettingInfoEditor and NMMetaPropertyInfo are
conceptionally very similar: the describe a certain type and provide
accessors.
In nmcli we have yet another NMMetaAbstractInfo type: NmcOutputField
will be modified to become another implementation of meta data (it
already is, it just cannot be used interchangable with the other
types).
Also, embed the NMMetaSettingInfoEditor in the NMMetaPropertyInfo
instance. This allows from a given NMMetaPropertyInfo to retrieve it's
parent NMMetaSettingInfoEditor.
"nm-meta-setting-desc.h" contains static type description, vtable and (internal)
accessor functions. Add accessor functions that operate on top of the type description
to "nm-meta-setting-access.h".
This check requires additional information about the environment, that
is about the present connections in NMClient.
"nm-meta-setting-desc.c" should be independent from the libnm D-Bus
cache, hence move this code to "settings.c".
The lower layers are concerned with handling settings. They should not
be aware of how to notify about warnings. Instead, signal them via
the warn_fcn() hook.
We should not violate the global data to track the output data
while it is constructed and printed.
Most of the time, we actually clear the output data anyway --
either before constructing it, or after printing it.
In some cases we didn't, but I think that is a bug. It's really
hard to keep track of this.
The output data should belong to a certain scope and get destroyed
afterwards. Passing it around is very confusing. Don't do that.
To better understand which part of the code have side effects,
split print_data() in a part that mutilates the input array
and a part that only prints.
The NmCli structure is passed around everywhere and contains all
the state of the program. It is very hard to follow which parts
are used where.
Split out more configuration options to a NmcConfig field. This field
is mostly immutable, and modified at particular places that now can be
easily found.
Otherwise, changing the structure is difficult because it all depends
on the order (and you don't immdiately see which field is used where).
Also, drop the name_l10n field.
These functions are only used by nm-meta-setting-desc.c. Make them internal.
Unfortunately, they are part of "common.h" which cannot be used without
the rest of nmcli. Still todo.
This part contains static functions and variables to describe
settings. It is distinct from the mechanism to use them, or
access them.
Split it out.
It still uses clients/cli/common.h and clients/cli/utils.h
which shall be fixed next.
They will be moved out of nmcli as they are generally useful.
Even if they happen to be used only inside nmcli, there should
be a better separation between logic (nmcli) and setting decriptions.
Mostly these strings are static. In same cases they are generated
however. Instead of caching them in a static variable, return them
to the caller.
And belatedly fix invoking describe_fcn().
settings.c basically consists of property-type structures and *a lot* of
accessors. All these accessors share the same argument list.
It is very repetitive to specify it over and over again. Also, there
are so many arguments that one is compelled to wrap the lines. All
in all it results in a lot of noise that takes the eye from the important
code.
Also, the argument list is expected to change, so we possibly only
have to change one place.
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.
