Added signal to DBus interface

[jdrescher2006]

Added a signal to DBus interface which is fired if a button is pressed within a watch app. The signal has UUID and button key as parameters.

[jdrescher2006]

I hope everything is right, at least it works.

[abranson]

Ok, I'll give this a test later on, and maybe remove that previous one. I'm not sure if this wouldn't be better if specifically subscribed to by an app, rather than just sending out every unknown keypress (rare though they will be). Need to review how the old Pebble API worked, and how GadgetBridge handles this.

[jdrescher2006]

I think you're right, my solution is a little bit quick&dirty. So I looked into GadgetBridge. You can see in the sports api https://developer.pebble.com/guides/communication/using-the-sports-api/#handling-button-events that android apps can register a receiver for when the button is pressed. In the GadgetBridge log https://talk.maemo.org/attachment.php?attachmentid=39375&d=1496234264, you can see the button events coming in at 14:05:15.965 and 14:05:27.360. If you search for the log entries in the GadgetBridge code you will find the right places.

[jdrescher2006]

That said I still don't know how to do things better. We have to use signals http://nemo-qml-plugin-dbus.readthedocs.io/en/latest/#id2 from QML code. Maybe we can provide a signal that has the UUID of the watch app as name. Then the SFOS app can listen to that specific signal. I don't know if that is possible.

[abranson]

Thanks for the link, I will look at that. I think rather than emitting signals for the appids that are unknown, which will only work for those weird built-in apps, I can add a call to allow SFOS apps to request their own appids. However, I don't think that will affect what you're doing - even if you don't get chance to add the request quickly, Rockpool can still emit the unknowns. So I'll merge this for now. I'll drop the callback one though if you're not going to use it.

[jdrescher2006]

Thanks for merging. I will not use the callback function, you can drop it.

[abranson]

Ok will do. Is everything finished on your end now? I should wait until you're ready before I build and release this, in case there's something else you need to add.

[jdrescher2006]

If it's OK maybe you could give me a few days to complete the pebble integration in my app. I will report back here when i'm ready.

[abranson]

No problem at all. Good luck!

[jdrescher2006]

org.rockwork.Manager gives me a list of known pebbles. Is it somehow possible to get the address of the connected pebble?

[jdrescher2006]

I have an other problem now. I try to add ListWatches() and Version() as DBus properties. But that does not work. It seems to have something to do with the Q_SCRIPTABLE statement (dbusinterface.h):
`
class DBusInterface : public QObject
{
Q_OBJECT
Q_CLASSINFO("D-Bus Interface", "org.rockwork.Manager")
Q_PROPERTY(QList ListWatches READ ListWatches)
Q_PROPERTY(QString Version READ Version)

public:
explicit DBusInterface(QObject *parent = 0);

public slots:
Q_SCRIPTABLE QString Version();
Q_SCRIPTABLE QList ListWatches();

signals:
Q_SCRIPTABLE void PebblesChanged();
void NameChanged();

private slots:
void pebbleAdded(Pebble *pebble);
void pebbleRemoved(Pebble *pebble);

private:
QHash<QString, DBusPebble*> m_dbusPebbles;
};
`

[jdrescher2006]

HI abranson, I managed to get everything to work by using C++ functions.

If you like, you can now release this version.

[abranson]

Ok, I just need to get to the bottom of a crash on closing notifications, then I'll go for a new release. Thanks for the integration!