D21584: Add LE Advertising and GATT APIs

[Manuel Weichselbaumer]

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

INLINE COMMENTS

> drosca wrote in objectmanager.h:47
> I don't really like this class at all. This is implementation detail, and is of no use for the users of the library, so it shouldn't be exported. On top of it, there is actually no code, it is just interface class.
> 
> Another issue here, although minor, is that the bluezqt_dbustypes.h is not installed, so you can't use it. Yes, you could install it, but we don't need it.
> 
> As I can see, the only reason for this class is so you can pass it to ObjectManagerAdaptor, but there are other ways to achieve the same thing without adding `ObjectManager` and deriving from it in GattApplication. If we really need it in generic way, we can do it later.
> 
> Something like this would work:
> 
>   ObjectManagerAdaptor(QObject *parent)
>   {
>       GattApplication *app = qobject_cast<GattApplication*>(parent);
>   }
>   
>   DBusManagerStruct GetManagedObjects()
>   {
>       return app->d->getManagedObjects();
>   }
> 
> Or for now just make it work only with GattApplication, as this is the only one we have now.
> 
> Yes, it will not work in the autotest, since you won't have the hook anymore, but you can just remove that test.

I see your point and agree, that ObjectManager is solely used in GattApplication.
Just letting you know, that we would need an ObjectManager for the mesh-api as well.

Shall we then add constructors for appropriate types to ObjectManagerAdaptor (instead of exporting and inheriting from ObjectManager)?

REPOSITORY
  R269 BluezQt

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

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/20190607/2e039596/attachment.html>