The same issue seems to be present in [3.4.0.22] Voicecall-ui uses CPU on the background - #10 by Fuzzillogic albeit a bit more subtle (less drain). Each time I get a call (which is also used as MFA for work) I have to restart the home screen using the utilities, as not to end up with prematurely flat battery.
Itâs more common than I thought⌠Iâve received a plethora of email, SMS, Whisperfish and WhatsApp notifications today, and some of them flash before disappearing, some of them scroll the text quickly to the end and then disappear, an some of them work as expected (slow scroll until the end of the text, until the timeout is reached). I think it something fundamental in the notification system in Silica that causes it, but how on earth to debug such issue?
Iâll give the patch a go, letâs see if it helpsâŚ
Now the animation is somewhat pretty around the âaction buttonsâ of the notifications in the event view as the notification is expanded and shrunk.
haveThingsdoes not update when thing.count changes, unless there is a signal implemented somewhere. Is that correct?
Because the file in question has:
property int visibleCount: {
var count = 0
if (notification) {
var actions = notification.remoteActions
for (var i = 0; i < actions.length; i++) {
var name = actions[i].name
if (name && name.length > 0 && name !== "default" && name !== "app") {
count = count + 1
}
}
}
return count
}
// ... and later
property bool _active: active && visibleCount > 0
// ... and then our suspected-to-be-broken
opacity: _active ? 1.0 : 0.0
Behavior on opacity { FadeAnimator {}}
enabled: _active
Is it possible that visibleCount doesnât update correctly/reliably?
In your Thing example, the count is a property , so a signal is automatically associated to it. Using it in a JavaScript piece of code makes this piece of code reevaluated if count is changed. I mean when this piece of JavaScript is used as a binding to something, like in your example.
Just to complete my education: if Thing is implemented by me in C++ and I do not emit a signal on changes in my code, then it will not reevaluate, correct?
Indeed. My reply was corresponding to your snippet in pure QML. Thing can be implemented in C++ with count declared as a property with a READ function and a CHANGED signal. And last be not least, the latter signal must be emitted each time the former read function would evaluate to a different value. Then, it would behave as described with JavaScript piece of code reevaluated each time count is changing.
After applying this, I didnât get any CPU drains from lipstick, but after upgrading to 4.4.0.64, which reverted it, I started getting them again⌠Two times today already.
Itâs really a hit-and-miss work trying to pin this down⌠Any ideas making it easier are miat appreciated!