fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2026-05-08 19:28:04 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/clients/tui/nm-editor-bindings.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

57 lines
3.2 KiB
C
Raw Permalink Normal View History

all: unify comment style for SPDX-License-Identifier tag Our coding style recommends C style comments (/* */) instead of C++ (//). Also, systemd (which we partly fork) uses C style comments for the SPDX-License-Identifier. Unify the style. $ sed -i '1 s#// SPDX-License-Identifier: \([^ ]\+\)$#/* SPDX-License-Identifier: \1 */#' -- $(git ls-files -- '*.[hc]' '*.[hc]pp')
2020-09-29 16:42:22 +02:00
/* SPDX-License-Identifier: GPL-2.0+ */
nmtui: initial import of nmtui nmtui is a TUI (curses-based Text User Interface) for NetworkManager
2013-12-02 16:20:26 -05:00
/*
all: unify format of our Copyright source code comments ```bash readarray -d '' FILES < <( git ls-files -z \ ':(exclude)po' \ ':(exclude)shared/c-rbtree' \ ':(exclude)shared/c-list' \ ':(exclude)shared/c-siphash' \ ':(exclude)shared/c-stdaux' \ ':(exclude)shared/n-acd' \ ':(exclude)shared/n-dhcp4' \ ':(exclude)src/systemd/src' \ ':(exclude)shared/systemd/src' \ ':(exclude)m4' \ ':(exclude)COPYING*' ) sed \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[-–] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C1pyright#\5 - \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[,] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C2pyright#\5, \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C3pyright#\5#\7/' \ -e 's/^Copyright \(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/C4pyright#\1#\3/' \ -i \ "${FILES[@]}" echo ">>> untouched Copyright lines" git grep Copyright "${FILES[@]}" echo ">>> Copyright lines with unusual extra" git grep '\<C[0-9]pyright#' "${FILES[@]}" | grep -i reserved sed \ -e 's/\<C[0-9]pyright#\([^#]*\)#\(.*\)$/Copyright (C) \1 \2/' \ -i \ "${FILES[@]}" ``` https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/298
2019-10-01 09:20:35 +02:00
* Copyright (C) 2013 Red Hat, Inc.
nmtui: initial import of nmtui nmtui is a TUI (curses-based Text User Interface) for NetworkManager
2013-12-02 16:20:26 -05:00
*/
#ifndef NM_EDITOR_BINDINGS_H
#define NM_EDITOR_BINDINGS_H
tui: fix binding of some int/uint properties (rh #1078281) GLib registers number->string value transforms (meaning that number-valued properties like NMSettingVlan:id or NMSettingWired:mtu get loaded into their NmtNewtEntries correctly), but not the corresponding string->number transforms (meaning changes made in the entries don't get propagated back to the settings, and due to http://bugzilla.gnome.org/show_bug.cgi?id=726574, there's no warning about this). Fix this by registering our own transforms.
2014-03-17 15:39:08 -04:00
void nm_editor_bindings_init(void);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core, all: merge IPv4 and IPv6 address/route types Merge NMIP4Address and NMIP6Address into NMIPAddress, and NMIP4Route and NMIP6Route into NMIPRoute. The new types represent IP addresses as strings, rather than in binary, and so are address-family agnostic.
2014-09-16 16:42:46 -04:00
void nm_editor_bind_ip_addresses_with_prefix_to_strv(int family,
gpointer source,
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
const char * source_property,
nmtui: initial import of nmtui nmtui is a TUI (curses-based Text User Interface) for NetworkManager
2013-12-02 16:20:26 -05:00
gpointer target,
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
const char * target_property,
nmtui: initial import of nmtui nmtui is a TUI (curses-based Text User Interface) for NetworkManager
2013-12-02 16:20:26 -05:00
GBindingFlags flags);
libnm-core, all: merge IPv4 and IPv6 address/route types Merge NMIP4Address and NMIP6Address into NMIPAddress, and NMIP4Route and NMIP6Route into NMIPRoute. The new types represent IP addresses as strings, rather than in binary, and so are address-family agnostic.
2014-09-16 16:42:46 -04:00
void nm_editor_bind_ip_addresses_to_strv(int family,
gpointer source,
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
const char * source_property,
nmtui: initial import of nmtui nmtui is a TUI (curses-based Text User Interface) for NetworkManager
2013-12-02 16:20:26 -05:00
gpointer target,
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
const char * target_property,
nmtui: initial import of nmtui nmtui is a TUI (curses-based Text User Interface) for NetworkManager
2013-12-02 16:20:26 -05:00
GBindingFlags flags);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
tui: fix gateway editing Since adding NMSettingIPConfig:gateway, we were just binding that property to the Gateway entry as a string. But this caused two different problems: first, we were trying to set the :gateway property from the entry even when the IP address in the entry was incomplete (causing warnings), and second, we were no longer enforcing the rule that the gateway can only be set when there are static addresses configured. Fix this by adding back nm_editor_bind_ip_gateway_to_string(), but with new semantics reflecting the new way NMSettingIPConfig:addresses and :gateway work. (Besides just fixing the new bugs, this also makes the Gateway entry insensitive when there are no addresses; before, nmtui would allow you to type there, but the value would not be saved.) Fixes: Test263_nmtui_ipv4_addresses_delete_ip_and_back_to_auto https://bugzilla.gnome.org/show_bug.cgi?id=740017
2014-11-12 09:02:32 -05:00
void nm_editor_bind_ip_gateway_to_string(int family,
NMSettingIPConfig *source,
gpointer target,
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
const char * target_property,
const char * target_sensitive_property,
tui: fix gateway editing Since adding NMSettingIPConfig:gateway, we were just binding that property to the Gateway entry as a string. But this caused two different problems: first, we were trying to set the :gateway property from the entry even when the IP address in the entry was incomplete (causing warnings), and second, we were no longer enforcing the rule that the gateway can only be set when there are static addresses configured. Fix this by adding back nm_editor_bind_ip_gateway_to_string(), but with new semantics reflecting the new way NMSettingIPConfig:addresses and :gateway work. (Besides just fixing the new bugs, this also makes the Gateway entry insensitive when there are no addresses; before, nmtui would allow you to type there, but the value would not be saved.) Fixes: Test263_nmtui_ipv4_addresses_delete_ip_and_back_to_auto https://bugzilla.gnome.org/show_bug.cgi?id=740017
2014-11-12 09:02:32 -05:00
GBindingFlags flags);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core, all: merge IPv4 and IPv6 address/route types Merge NMIP4Address and NMIP6Address into NMIPAddress, and NMIP4Route and NMIP6Route into NMIPRoute. The new types represent IP addresses as strings, rather than in binary, and so are address-family agnostic.
2014-09-16 16:42:46 -04:00
void nm_editor_bind_ip_route_to_strings(int family,
gpointer source,
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
const char * source_property,
nmtui: initial import of nmtui nmtui is a TUI (curses-based Text User Interface) for NetworkManager
2013-12-02 16:20:26 -05:00
gpointer dest_target,
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
const char * dest_target_property,
nmtui: initial import of nmtui nmtui is a TUI (curses-based Text User Interface) for NetworkManager
2013-12-02 16:20:26 -05:00
gpointer next_hop_target,
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
const char * next_hop_target_property,
nmtui: initial import of nmtui nmtui is a TUI (curses-based Text User Interface) for NetworkManager
2013-12-02 16:20:26 -05:00
gpointer metric_target,
all: don't use gchar/gshort/gint/glong but C types We commonly don't use the glib typedefs for char/short/int/long, but their C types directly. $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l 587 $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l 21114 One could argue that using the glib typedefs is preferable in public API (of our glib based libnm library) or where it clearly is related to glib, like during g_object_set (obj, PROPERTY, (gint) value, NULL); However, that argument does not seem strong, because in practice we don't follow that argument today, and seldomly use the glib typedefs. Also, the style guide for this would be hard to formalize, because "using them where clearly related to a glib" is a very loose suggestion. Also note that glib typedefs will always just be typedefs of the underlying C types. There is no danger of glib changing the meaning of these typedefs (because that would be a major API break of glib). A simple style guide is instead: don't use these typedefs. No manual actions, I only ran the bash script: FILES=($(git ls-files '*.[hc]')) sed -i \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \ -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \ "${FILES[@]}"
2018-07-11 07:40:19 +02:00
const char * metric_target_property,
nmtui: initial import of nmtui nmtui is a TUI (curses-based Text User Interface) for NetworkManager
2013-12-02 16:20:26 -05:00
GBindingFlags flags);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
nmtui: initial import of nmtui nmtui is a TUI (curses-based Text User Interface) for NetworkManager
2013-12-02 16:20:26 -05:00
void nm_editor_bind_wireless_security_method(NMConnection * connection,
NMSettingWirelessSecurity *s_wsec,
gpointer target,
const char * target_property,
GBindingFlags flags);
void nm_editor_bind_wireless_security_wep_key(NMSettingWirelessSecurity *s_wsec,
gpointer entry,
const char * entry_property,
gpointer key_selector,
const char * key_selector_property,
GBindingFlags flags);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
all: stop using virtual interface-name properties The virtual :interface-name properties (eg, NMDeviceBond:interface-name) are deprecated in favor of NMSettingConnection:interface-name, and nm_connection_verify() ensures that their values are kept in sync. So (a) there is no need to set those properties when we can just set NMSettingConnection:interface-name instead, and (b) we can replace any calls to the setting-specific get_interface_name() methods with nm_connection_get_interface_name() or nm_setting_connection_get_interface_name().
2014-08-05 14:13:42 -04:00
void nm_editor_bind_vlan_name(NMSettingVlan *s_vlan, NMSettingConnection *s_con);
nmtui: initial import of nmtui nmtui is a TUI (curses-based Text User Interface) for NetworkManager
2013-12-02 16:20:26 -05:00
#endif /* NM_EDITOR_BINDINGS_H */
Reference in a new issue Copy permalink