|Summary:||KPassivePopup does not have close button/close on click|
|Product:||[Frameworks and Libraries] frameworks-knotifications||Reporter:||Andrea Scarpino <scarpino>|
|Component:||general||Assignee:||Martin Klapetek <mklapetek>|
|Latest Commit:||Version Fixed In:|
|Attachments:||Screencast of the issue|
Description Andrea Scarpino 2014-10-22 20:59:59 UTC
Comment 1 Martin Klapetek 2014-10-22 21:06:21 UTC
> The notification popup and there's no way to close it That's not true, each notification has a hardcoded close button. Can you post a screenshot of your popup? I'm against having close-on-clicking-anywhere as notifications also have buttons, if you misclick just by one single pixel, instead of launching the action it would close. > Also, the notification doesn't go away after some time, instead it stays there forever and it "blinks" like if it goes away and then immediately appears again. Which notification is that? All non-persistent notifications are never stored anywhere. Plus there's nothing that would blink. Can you post a screenshot/video of that as well please? > The notification popup and hides after some time Every notification has a timeout, it does auto hide. If you mean from the notification history (the applet that expands from systray), there's also a timer albeit a bit longer (these notifications are persistent so, well, they need to persist).
Comment 2 Martin Klapetek 2014-10-23 12:38:22 UTC
Clarification after IRC discussion: * the report talks about notifications falling back to KPassivePopup as there is no Plasma running and therefore no notifications handler * KPassivePopup is the ultimate fallback * KPassivePopup does not offer a close button and it should * KPassivePopup (imo) should not offer click-to-close for the same reasons stated in comment #1 * KPassivePopup may or may not have an actual timer for non-persistent notifications; it should have
Comment 3 Martin Klapetek 2014-10-31 11:31:15 UTC
An update: > * KPassivePopup (imo) should not offer click-to-close for the same reasons stated in comment #1 KPassivePopup does have a code that closes it on clicking. I successfully tested it as well. > * KPassivePopup may or may not have an actual timer for non-persistent notifications; it should have Timers are indeed broken, fix in https://git.reviewboard.kde.org/r/120854/
Comment 4 Andrea Scarpino 2014-10-31 16:18:09 UTC
Created attachment 89393 [details] Screencast of the issue Still not fixed with that patch. A screencast is attached.
Comment 5 Martin Klapetek 2014-11-03 17:39:40 UTC
The patch fixes only the timers so that it will autohide after the timeout. As for click-to-hide, KPassivePopup has this code: connect(q, SIGNAL(clicked()), q, SLOT(hide())); and the clicked() signal is emitted from KPassivePopup::mouseReleaseEvent(). I have one possible suspicion about what could be wrong, however can you please confirm that knotifications/tests/kpassivepopuptest has the same problem?
Comment 6 Martin Klapetek 2014-11-06 11:36:49 UTC
Git commit 38fcc9e7950a88138f09b67916ce6d4b5233cb05 by Martin Klapetek. Committed on 06/11/2014 at 11:36. Pushed by mklapetek into branch 'master'. KPassivePopup - Set default hide delay REVIEW: 120854 M +4 -4 src/kpassivepopup.cpp http://commits.kde.org/knotifications/38fcc9e7950a88138f09b67916ce6d4b5233cb05
Comment 7 Andrea Scarpino 2014-11-09 21:52:02 UTC
Hi, sorry for the late reply. Using the test I cannot reproduce the issue with any of the notifications shown.
Comment 8 Andrea Scarpino 2014-12-29 20:12:30 UTC
I cannot reproduce this using 'dunst'. So, maybe it's an awesomewm issue? However, KDE4 notifications still works in awesomewm, while KNotifications5 does not.
Comment 9 Andrea Scarpino 2015-03-14 08:47:43 UTC
Still an issue with KF 5.8
Comment 10 Andrea Scarpino 2015-04-04 08:26:00 UTC
The second issue was AwesomeWM fault (https://github.com/awesomeWM/awesome/issues/190) and it's fixed in current git.