1. 12 Feb, 2019 1 commit
  2. 17 Jul, 2018 1 commit
  3. 11 Jul, 2018 1 commit
    • Thomas Haller's avatar
      all: don't use gchar/gshort/gint/glong but C types · e1c7a2b5
      Thomas Haller authored
      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[@]}"
      e1c7a2b5
  4. 27 Jun, 2017 2 commits
  5. 12 May, 2017 2 commits
    • Thomas Haller's avatar
      hostname: cache hostname-manager's hostname property · 54f5407a
      Thomas Haller authored
      A property preferably only emits a notify-changed signal when
      the value actually changes and it caches the value (so that
      between property-changed signals the value is guaranteed not to change).
      
      NMSettings and NMManager both already cache the hostname, because
      NMHostnameManager didn't guarantee this basic concept.
      
      Implement it and rely on it from NMSettings and NMPolicy.
      And remove the copy of the property from NMManager.
      
      Move the call for nm_dispatcher_call_hostname() from NMHostnameManager
      to NMManager. Note that NMPolicy also has a call to the dispatcher
      when set-transient-hostname returns. This should be cleaned up later.
      54f5407a
    • Thomas Haller's avatar
      hostname: split out hostname management from NMSettings · 5bfb7c3c
      Thomas Haller authored
      Hostname management is complicated. At least, how it is implemented currently.
      For example, NMPolicy also sets the hostname (NMPolicy calls
      nm_settings_set_transient_hostname() to have hostnamed set the hostname,
      but then falls back to sethostname() in settings_set_hostname_cb()).
      Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and
      NMPolicy listens to changes from there -- instead of changes from
      NMSettings.
      
      Eventually, NMHostnameManager should contain the hostname parts from NMSettings
      and NMPolicy.
      5bfb7c3c