KActivities::Consumer::currentActivityChanged() signals an activity change without any corresponding change of activity.
It should not do that, there is a check in src/lib/activitiescache_p.cpp:304 for that. Do you have a way for me to replicate this?
This looks like it happens at signal connection. connect(m_activitiesConsumer, &KActivities::Consumer::currentActivityChanged, [=] { activityChanged(m_activitiesConsumer->currentActivity()); Q_EMIT statusChange(); } Commenting out "Q_EMIT statusChange()" works around a signal trigger.
Created attachment 103451 [details] Avoid signalling if the previous activity matches the nulluuid. This patch avoids signalling that the current activity has changed when the activity it is changing from matches the nulluuid value.
The attached patch does fix the issue.
But is the patch also committed?
Should I leave this for Ivan?
Reopening the bug. Please only close if the patch is committed.
OK, sorry.
(In reply to Christoph Feck from comment #7) > Reopening the bug. Please only close if the patch is committed. Any time frame for when that may happen?
The attached patch is wrong, or I don't see the reasoning behind it. null uuid activity is a valid activity value that applications should handle and know about. If an application gets 'current activity is null' it needs to get 'current activity is not null as well'. If you want to ignore null uuid, you can do it downstream (like plasma mostly does).
Checking for a nullid fails. If I compare the incoming activity id with currentActivity(), they match, which makes sense. This looks like it happens each time the connecting object is constructed, which can happen when no activity change is occurring. In this situation no activity changed signal should be emitted. There's really no workaround either, it just shouldn't be emitted.
When the application starts, it does not have all the data synchronized with the activity manager (the API is completely non-blocking). For it, the current activity is null until it gets the data. When the data is received, then the signal is sent - the activity is changed from the null activity to the proper one. Do you listen to the serviceStatusChanged signal? When it becomes Running, this should meant that the sync is complete.
Checking if the service is running seems to work.