1. 01 Feb, 2019 4 commits
    • 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).
  2. 27 Jan, 2019 2 commits