Re: [Announce] Pebble Watch Connector daemon
 

Hi Smoku,

Thank you so much for the pebble app. I can't believe how lucky we are to have such a high quality open source app for Sailfish, especially when the app for Android is proprietary!

I now have it working well, but one thing I noticed is that I wasn't getting XMPP messages through until I unchecked and re-checked the option for Messaging notifications. Is this something you've seen before? I was thinking maybe the default config file might have different options to what's shown in the GUI or something like that?

Thanks again! :)

Re: [Announce] Pebble Watch Connector daemon
 

Yes. We have had an issue with setting default value of setting to true. Even though UI "thinks" it is true, the demon "thinks" it is false. Looks like it is back with new Qt version. Checking off/on fixes it.

I have no good idea how to fix it... :(

Re: [Announce] Pebble Watch Connector daemon
 

Thanks for the reply. Out of curiosity i had a look at the code, it's very readable! I wish I could write like that.

So are you saying the bug disappeared and reappeared with the last couple of updates to qt? Do you know of any other sailfish apps that have had similar issues?

Re: [Announce] Pebble Watch Connector daemon
 

We fixed it.
But it looks like the fix stopped working with the upgrade to Qt 5.2.
It is hard to debug, as it does not have a stable reproduction.


Are there any other apps architectured as a daemon + configuration app tandem?

Re: [Announce] Pebble Watch Connector daemon
 

I already mentioned about it in here:
http://talk.maemo.org/showpost.php?p...&postcount=216

It is not easily reproducible because an unitialized variable (e.g. Settings::incomingCallNotification) is being read (valgrind should complain).

QObject->property() will only return an invalid variant if the property does not exist. The property exists (it is not dynamic, since it is declared via Q_PROPERTY), and therefore the isValid() check is useless (always returns true).

Thus, even if the dconf setting does not exist, the current value of Settings::incomingCallNotification is read. This is not initialized in the constructor (which doesn't initialize much), and certainly is not initialized by MDConfGroup (because the setting does not exist in dconf yet).

Therefore, a random value is read.

Sorry I don't have time to make a patch atm, but it should be as trivial as changing the settings.h constructor to initialize the member variables to the proper default values.

Re: [Announce] Pebble Watch Connector daemon
 

Thanks both of you!

I don't have much programming experience (I'm a Civil Engineer) but am keen to learn - I use Plasma Desktop on my laptop so learning some Qt will be a double win because I can use it with both Sailfish and any desktop apps I write.

Explanations like above really help with the learning, I hope I'll be good enough to contribute to projects like this soon.

Thanks again :)

Re: [Announce] Pebble Watch Connector daemon
 

Ouch! I missed that.
MDConf returns invalid QVariant for non-existing values. But in MDConfGroup there is an explicit check not to store invalid QVariant.
Also like you noticed, QObject would not return one anyway.


I'm hesistant to such change as it would mean storing default values both in daemon and app and a need to keep them synchronized.

Re: [Announce] Pebble Watch Connector daemon
 

But... If I see correctly, we could in constructor: set defaults, resolveProperties() and then call MDConfGroup::propertyChanged() to flush all (defaults + read properties) back to DConf, right?

Re: [Announce] Pebble Watch Connector daemon
 

The current situation is much worse where you're doing that implicitly depending on how the ->isValid() checks are wired :)

But generally I agree, I just wish there was an easy way to package+install dconf schemas in Mer... I have hit this in almost every Jolla program I've made.

Re: [Announce] Pebble Watch Connector daemon
 

Agreed of course. :D
But I would like to fix it once-for-all well, not with some cludges.