D22107: Add MediaTransport API

[Manuel Weichselbaumer]

mweichselbaumer marked an inline comment as done.
mweichselbaumer added inline comments.

INLINE COMMENTS

> drosca wrote in a2dp-codecs.h:33
> Are you sure about this?

Yes, this has also been fixed by bluez as of 2018-12-28.

> drosca wrote in tpendingcall.h:45
> Is this really needed? In the end, it doesn't really make the code that much better:
> 
>   TPendingCall<QDBusUnixFileDescriptor, uint16_t, uint16_t> *fd = transport->tryAcquire();
>   fd->valueAt<0>();
>   fd->valueAt<1>();
>   fd->valueAt<2>();
> 
> vs
> 
>   PendingCall *fd = transport->tryAcquire();
>   fd->values().at(0).value<QDBusUnixFileDescriptor>();
>   fd->values().at(1).value<uint16_t>();
>   fd->values().at(2).value<uint16_t>();
> 
> Or we can add convenience method  `T valueAt(int)` so it becomes:
> 
>   PendingCall *fd = transport->tryAcquire();
>   fd->valueAt<QDBusUnixFileDescriptor>(0);
>   fd->valueAt<uint16_t>(1);
>   fd->valueAt<uint16_t>(2);

Actually, my intention was to provide a type-safe way to obtain return values from PendingCall and to express explicitly, what the corresponding method returns in API header.
As a client you can make use of "auto".

Consider:

  auto *fd = transport->tryAcquire(); // Method declaration will define return type.
  auto ret1 = fd->valueAt<0>();
  auto ret2 = fd->valueAt<1>();
  auto ret3 = fd->valueAt<2>();

Thus, return type (of PendingCall) is expressed in API header and clients do not need to express the return types themselves.

REPOSITORY
  R269 BluezQt

REVISION DETAIL
  https://phabricator.kde.org/D22107

To: mweichselbaumer, drosca
Cc: kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190627/4ab2d9ae/attachment-0001.html>