Skip to content
Snippets Groups Projects
  1. Jan 21, 2021
  2. Nov 15, 2020
  3. Oct 22, 2020
  4. Jun 15, 2020
  5. Jun 12, 2020
  6. Jun 10, 2020
    • George Kiagiadakis's avatar
      impl-node: subclass from GObject · 7a486f1f
      George Kiagiadakis authored
      By mistake, WpImplNode was developed by keeping in mind that the proxy
      returned by pw_core_export() is a PW_TYPE_INTERFACE_Node, but this
      is not true. It's actually a ClientNode...
      
      Unfortunately, making WpImplNode work as if it was a WpNode is
      not so easy, especially when it comes to handling params, which
      need to be queried syncrhonously on the underlying spa_node.
      
      So, instead of fixing WpImplNode to work as a WpNode, we choose to
      disconnect them. This way, WpImplNode will not be used as a proxy
      in the registry and the registry will normally create WpNode proxies
      instead, making round-trips through the server to change node params.
      7a486f1f
  7. Jun 02, 2020
  8. May 29, 2020
  9. May 14, 2020
  10. May 13, 2020
  11. May 03, 2020
  12. Feb 28, 2020
  13. Feb 26, 2020
  14. Feb 25, 2020
  15. Feb 14, 2020
    • George Kiagiadakis's avatar
      object-manager: refactor to be able to track locally created proxies · 753e7085
      George Kiagiadakis authored
      There are 3 kinds of WpProxy objects:
       * the ones that are created as a result of binding a global
         from the registry
       * the ones that are created as a result of calling into a remote
         factory (wp_node_new_from_factory, etc...)
       * the ones that are a local implementation of an object
         (WpImplNode, etc...) and are exported
      
      Previously the object manager was only able to track the first kind.
      With these changes we can now also have globals associated with
      WpProxies that were created earlier (and caused the creation of the global).
      This saves some resources and reduces round-trips (in case client
      code wants to change properties of an object that is locally
      implemented, it shouldn't need to do a round-trip through the server)
      753e7085
  16. Feb 12, 2020
  17. Feb 11, 2020
    • George Kiagiadakis's avatar
      proxy/core: refactor object creation · 9330208a
      George Kiagiadakis authored
      * core no longer exposes create_remote/local_object
      * node, device & link have constructor methods
        to enable the create_remote_object functionality
      * added WpImplNode to wrap pw_impl_node and allow creating
        "local" node instances
      * added WpSpaDevice to wrap spa_device and allow creating
        "local" device instances
      * exporting objects in all cases now happens by requesting
        FEATURE_BOUND from the proxy, eliminating the need for WpExported
      * replaced WpMonitor by new, simpler code directly in module-monitor
      * the proxy type lookup table in WpProxy is gone, we now
        use a field on the class structure of every WpProxy subclass
        and iterate through all the class structures instead; this is
        more flexible and extensible
      9330208a
  18. Jan 22, 2020
  19. Jan 13, 2020
  20. Jan 09, 2020
Loading