| 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> |
| Status: | RESOLVED DOWNSTREAM | ||
| Severity: | normal | CC: | kdelibs-bugs, simonandric5 |
| Priority: | NOR | ||
| Version: | 5.1.0 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Screencast of the issue | ||
|
Description
Andrea Scarpino
2014-10-22 20:59:59 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). 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 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/ Created attachment 89393 [details]
Screencast of the issue
Still not fixed with that patch. A screencast is attached.
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?
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 Hi, sorry for the late reply. Using the test I cannot reproduce the issue with any of the notifications shown. I cannot reproduce this using 'dunst'. So, maybe it's an awesomewm issue? However, KDE4 notifications still works in awesomewm, while KNotifications5 does not. Still an issue with KF 5.8 The second issue was AwesomeWM fault (https://github.com/awesomeWM/awesome/issues/190) and it's fixed in current git. |