It can happen that a notification is placed in the show queue and then
it's closed (eg. programatically) before it was even shown. In this case
the notification must be cleared from the show queue otherwise it will
get displayed and hidden but the popup is never freed for reuse,
resulting in notificaions starting at higher position from the panel.
BUG: 342605
It can happen that a notification is placed in the show queue and then
it's closed (eg. programatically) before it was even shown. In this case
the notification must be cleared from the show queue otherwise it will
get displayed and hidden but the popup is never freed for reuse,
resulting in notificaions starting at higher position from the panel.
BUG: 342605
There were situations when the same notification popup could be be
inserted twice into the available popups list, breaking the positioning
as it would create more notifications than it was able to but they would
never get closed and would offset the whole stack.
One of such scenarios was when user manually closed the popup with the
close button. After it was hidden, the hiding timer still went on to
fire and close it again, causing the above.
Should be all fixed now.
BUG: 342605
When a job finishes, it has an Open button. But we need to check if we
actually have a valid URL first. QUrl::fromUserInput().isValid() seems
like a perfect fit, but as it's not available in QML, I've added it as a
singleton to the notifications helper.
Reviewed-by: Kai Uwe Broulik
This prevents some apps to spam lots of notifications when all it needs
is actually just one single notification.
Imagine you're switching songs in your playlist quickly and each song
change sends new notification, but when you get to the tenth song, you
still see the notification from the 3rd song (because timeouts) and you
don't really care about all those songs changes still in the queue as
you see it in the playlist anyway.
So this patch limits certain apps to have only one single notification
which is always updated. So far Clementine and Spotify is there.
Switching songs or changing playback status creates only one single
popup.
Additionally, the list gets added entries from a config file too.
REVIEW: 118796
Up to this patch there was a new Dialog created for each and every new
notification incoming. After the notification was timed out, it would
close and delete the Dialog, but somehow that didn't free all the memory
and over time plasma-shell could get huuuge mem usage.
Now the notifications reuse only 3 Dialogs the whole lifetime --> memory
does not skyrockets anymore.
Note that the original leak in Dialog might still be present, but
notifications do not expose it anymore.
BUG: 333029
REVIEW: 117903
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
techbase wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://community.kde.org/Frameworks/GitOldHistory
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo kde-workspace, frameworks branch, at commit
049113e719dd2fc4446d054fa1a3aada330094f0
Martin Klapetek
Montel Laurent
Jonathan Riddell
Kai Uwe Broulik
Aleix Pol