The fix for this will probably look like dismissing the existing notification (and therefore deleting that playlist) if another notification is created--and in fact, this is something we should have in place for all notifications, because stacked notifications are ugly and unnecessary.

I see this too - the in-app notifications for removing a playlist stack up on top of one another.

This isn't how in-app notifications should work: only one should be shown at once. If the user removes a playlist while an undo notification is being shown, the first notification should be immediately dismissed and replaced with the new one.

Created attachment 321184 [details] [review]
A patch to show one playlist deleted notification at a time

A patch to fix this issue.

Created attachment 321198 [details] [review]
A updated patch.

there was some unnecessary line in the above patch so i removed that one.

Created attachment 323916 [details] [review]
A updated patch.

Initial issues that felipe was complaing about that when two playlist that
are deleted one after other, deletes first one this is because signal
'item-activate' has been emited before playlist even remove from the
playlist model,
so i remove playlist from the playlist model before emit the signal.
 there should only be one notification at a time so we have to track
that whether notification has been attach to the overlay or not, if it is
then destroy old one and delete the playlist associate with  that. so
i introduce the variable self.pl_todelete_notification.

This patch will also solve the bug that was filled by me. Felipe if this is commited then please close the bug
https://bugzilla.gnome.org/show_bug.cgi?id=761988

Review of attachment 323916 [details] [review]:

Thanks for your patch.

It solves both issues for now. I hope we get to refactor the Playlist management code in the future to avoid such problems.

Pushed to master as 76a6e8f109807ea204cddf623a1eaf523187aa12.