nemomobile / libconnman-qt Goto Github PK

I use libconnman-qt with actual revisions of connman and ofono. When I've got cellular service as default route I've got signal with empty service from networkmanager.
I think it caused by https://github.com/nemomobile/libconnman-qt/blob/master/libconnman-qt/networkmanager.cpp#L337
this code does not meet expected flags (0003) in my case /proc/net/route looks like:
ppp0 8AA6B40A 00000000 0005 0 0 0 FFFFFFFF 0 0 0
ppp0 010057D5 00000000 0005 0 0 0 FFFFFFFF 0 0 0
ppp0 010157D5 00000000 0005 0 0 0 FFFFFFFF 0 0 0
ppp0 00000000 00000000 0001 0 0 0 00000000 0 0 0
I think in case of only one destionation is 00000000 it must consider as default route only with RTF_UP flag
flag & 0x1 // RTF_UP 0x0001

The file connman-qt4.pc is installed in 'lib' and 'lib/pkgconfig' folders. The file installed in 'lib' folder should be removed.

./usr/local/lib/connman-qt4.pc <------ TO BE Removed
./usr/local/lib/libconnman-qt4.so.1
./usr/local/lib/libconnman-qt4.prl
./usr/local/lib/libconnman-qt4.so.1.0
./usr/local/lib/libconnman-qt4.so.1.0.39
./usr/local/lib/pkgconfig
./usr/local/lib/pkgconfig/connman-qt4.pc
./usr/local/lib/libconnman-qt4.so

Guys,

I'm happy to see a nice amount of work in this plugin. It shows that's useful to a lot of people. I can surely say for the company I work for.

Anyway, what I want to discuss is the various changes that we have in this plugin. Some of them changes a lot of the way end-users (usually qml applications) would you the plugin.

I really think we need to define our goals, use cases that the plugin should support, clean and nice API, milestones to reach those goals then tagging the version, and so on.

I think we are a little bit disorganized. This may be a reason why there is another guy working in another connman library by him self instead of contributing here https://bitbucket.org/devonit/qconnman. (BTW he has some code from us)

What do you guys think? I hope can all discuss here and come up with a consensus.

The current version of connman-qt is 1.0.0 and the version of the declarative components is 0.2. This needs to be synchronized. Bump the version up to 1.0.

When a NetworkService object is constructed, there is a race condition where property changes may be missed and the NetworkService property cache will not have the proper values.

Sequence:

1. NetworkManager creates a NetworkService object, passing in the initial properties to be used in the NetworkService property cache
2. The NetworkService object constructor connects to the D-Bus object corresponding to it and sets up a connection from PropertyChanged signal on the D-Bus object to the updateProperty slot

Between steps 1 and 2, several properties may have been changed in the underlying service.

We'd better have more consistent coding style: don't use mix of keywords and Q_-macros, use macros only.