Bug 340238 - KPassivePopup does not have close button/close on click
Summary: KPassivePopup does not have close button/close on click
Status: RESOLVED DOWNSTREAM
Alias: None
Product: frameworks-knotifications
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.1.0
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Martin Klapetek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-22 20:59 UTC by Andrea Scarpino
Modified: 2015-04-04 08:26 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Screencast of the issue (710.84 KB, video/ogg)
2014-10-31 16:18 UTC, Andrea Scarpino
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrea Scarpino 2014-10-22 20:59:59 UTC
I don't know where to start to fix/workaround this, so I thought the first step is to report this issue to you.

I'm using AwesomeWM on top of Plasma 5 (well, except KWin, Plasma Desktop and KRunner).
When a notification popup there is no way to close it; in KDE 4 times a single click on it was enough.
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.

Reproducible: Always

Steps to Reproduce:
1. export KDEWM=awesome and disable Plasma autostart
2. exec startkde
3. wait for a notification or simulate it

Actual Results:  
The notification popup and there's no way to close it

Expected Results:  
The notification popup and hides after some time OR you can click on it to hide it.

KF 5.3.0
Plasma 5.1
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.