1. 26 Feb, 2019 1 commit
  2. 21 Feb, 2019 2 commits
  3. 12 Feb, 2019 1 commit
  4. 05 Feb, 2019 1 commit
    • Benjamin Berg's avatar
      libnm: Add async start/stop routines for P2P find operations · 60691d76
      Benjamin Berg authored
      These were dropped earlier as new sync API must not be the primary way
      of calling new routines in libnm.
      In this particular case the DBus calls are simple and unlikely to fail.
      Most users should use the normal async API and call the finish routine.
      However, if the API user is not interested in the result, then they can
      simply set the callback to NULL to ignore it.
      [thaller@redhat.com: added options argument to start-find method]
  5. 01 Feb, 2019 6 commits
    • Thomas Haller's avatar
      wifi-p2p: rename Wi-Fi P2P · 09090f26
      Thomas Haller authored
      After renaming the files, also rename all the content
      to follow the "Wi-Fi P2P" naming scheme.
    • Thomas Haller's avatar
      wifi-p2p: rename files for consistent Wi-Fi P2P naming · 0420fa1f
      Thomas Haller authored
      We named the types inconsistently:
        - "p2p-wireless" ("libnm-core/nm-setting-p2p-wireless.h")
        - "p2p" ("libnm/nm-p2p-peer.h")
        - "p2p-wifi" ("src/devices/wifi/nm-device-p2p-wifi.h")
      It seems to me, "libnm/nm-p2p-peer.h" should be qualified with a "Wi-Fi"
      specific name. It's not just peer-to-peer, it's Wi-Fi P2P.
      Yes, there is an inconsistency now, because there is already
      It seems to me (from looking at the internet), that the name "Wi-Fi P2P"
      is more common than "P2P Wi-Fi" -- although both are used. There is also
      the name "Wi-Fi Direct". But it's not clear which name should be
      preferred here, so stick to "Wi-Fi P2P".
      In this first commit only rename the files. The following commit will
      rename the content.
    • Thomas Haller's avatar
      libnm/device-p2p-wifi: drop API that still needs consideration · 6e45cd90
      Thomas Haller authored
      Having synchronous API is wrong, or at least questionable.
      Granted, libnm isn't currently very good about the exact order
      of things to happen. However synchronous API by design delays events
      while waiting for the response and hence messes up the ordering.
      Maybe synchronous API should not be added to libnm.
      Or at least, if we have synchronous API, we certainly need an asynchrnous
      variant as well (which is still missing).
      As synchronous API is not preferred, it should also be named
      nm_some_thing_sync(), accompanied by nm_some_thing() and
      nm_some_thing_finish(). The name for the synchronous method should be the
      odd one and we shouldn't have an nm_some_thing_async(). Yes, libnm is not
      consistend about that.
      I am going to drop this API for the moment.
    • Thomas Haller's avatar
      libnm/device-p2p-wifi: drop unused code · 4f8852b2
      Thomas Haller authored
      If this is going to be implemented, revert the patch.
    • Thomas Haller's avatar
      libnm: various cleanup of NMP2PPeer and NMDeviceP2PWifi · c6c41eb1
      Thomas Haller authored
      - fix leaking hw_address in finalize().
      - reorder code.
      - avoid double tabs in GObject property definitions.
      - hide struct definitions from header.
      - don't use signal slots in class structure.
      - add missing NM_AVAILABLE_IN_1_16 annotations.
    • Thomas Haller's avatar
      libnm/device-p2p-wifi: cleanup peers handling · 41b2d8c6
      Thomas Haller authored
      Don't reallocate peers-array nor set it to %NULL. Instead,
      just emit the signal for the peers and take them out one-by-one.
      I am slightly surprised, that the peers array does not need to hold
      a reference on the NMP2PPeer instances. But that seems intentional.
      I think, the libnm code here should be significantly reworked, but
      that is for another time.
      Also, delay clearing the pointers until finalize() method. For
      the most part, it shouldn't make a difference. Still avoid having
      the instance in a badly defined state during dispose() (which
      theoretically could be called multiple times).
  6. 27 Jan, 2019 2 commits