| Summary: | Plasma notification style ignores some parameters in KNotification::event | ||
|---|---|---|---|
| Product: | [Unmaintained] plasma4 | Reporter: | Dario Freddi <drf> |
| Component: | notifications | Assignee: | Rob Scheepmaker <rob> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | lars.g.kjellberg, lemma, mehrdad.momeny, michalodstrcil, ogoffart, rdieter, rob, vdboor |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Dario Freddi
2008-12-07 17:29:41 UTC
Added my vote, in KMess (version 2 in SVN) we're also hit by this bug. we use KNotification::setPixmap() to display a contact picture. In KDE 4.1 this was working, with the new plasma notifications this information is lost. Reassigning the bug The odd thing is, that kopete notifications (when somebody talks to you) do have persistent notifications. So those flags are respected there. I don't know what causes that difference in behavior though... I never really looked into the notification dataengine or knotification. This Also affects me, on my Twitter client app (choqoK) I need to set a custom timeout for notify, and i just found its KNotification::Persistent flag and a QTimer::singleShot() call. but this bug prevent it to work fine :-/ Does revision 909635 (or the backport of this to the 4.2 branch, I don't know which revision # that is) fix this problem for you? It fixed icon & application name, though the issue with the persistent flag still persists (sorry for the bad joke -.-) If the items still are not persistent, this is most likely a bug in knotification, since there is no code in the notification dataengine, or the systemtray that destroys notifications, they only get destroyed when knotification kills them. What happens when you try the oldschool notifications? (you can disable the plasma ones as described in http://pindablog.wordpress.com/2008/12/12/about-bugs-notifications-and-clean-blend/ ) Do you have Persistant=True in your app's .knotifyrc file? Everything worked (and still works) correctly with old style notifications. I did not set the flag in notifyrc, since sometimes I throw that notification persistently, sometimes not. Since it used to work, if knotifyrc entry is compulsory then the previous behavior was wrong, hence I'll modify my notifyrc and report, otherwise the bug still remains. Though, since you can specify the ::Persistent flag when calling KNotification, I think this should work even without specifying it in the rc file. Any follow up on this? Does it work when specifying persistent in the notifyrc? Now it gets all parameters correctly. I'll try with persistent now and report *** Bug 181119 has been marked as a duplicate of this bug. *** *** Bug 180871 has been marked as a duplicate of this bug. *** Unfortunately, this is still an issue. I added to notifyrc the Persistant (even tried Persistent) flag, no go. I copied all notification parameters from Kopete, nothing really changed. *** Bug 183084 has been marked as a duplicate of this bug. *** @Dario: do you by any chance have a value for timeout specified other then 0 in your notifyrc? That will override any persistent flag. Anyway, this is actually a knotify problem (yeah, I know it only happens on plasma notifications, but that's because knotify takes care of sending the info over dbus, or using the passivepopup, which are 2 different cases. On the plasma side we just listen for the notification to be killed: we don't even know the timeout time. I can't seem to figure out how to reassign this bug though... @Rob: No, I don't have a timeout specified. Though, if you point me to the relevant bits of code in the libs I could try fixing it. @Dario: ah, great :) You'll have to take a look at kdebase/runtime/knotify/notifybypopup.cpp... that's where the magic happens. It looks if org.kde.VisualNotification is on the dbus and sends it there if it is in sendDBusNotification IIRC. From my debug, the popup just disapears in plasma. And KNotify is not even aware the popup has been closed. @Olivier: ok, I assumed it was knotify's fault, since the only way I could get this to occur was by specifying a Timeout in notifyrc, which overruled the persistent flag. And in that case it was a knotify thing according to the debug output. Also, nowhere in plasma do we even receive the timeout or whether or not persistent is set. We only listen to terminate() being called over DBus by knotify. But of course something really freaky could be going on. Could you send me the test app you use that triggers this bug? (or a location I can download it myself) Hopefully that will help me determining exactly what's going on. Also 2 other pieces of information can help: * when the notification disappears, is the "i" icon (that shows/hides the trays popup) still in the systemtray? * if you quit plasma, then start plasmaengineexplorer, choose the "applicationjobs" engine and trigger your 'should be persistent' notification, does the notification disappear there after some time as well? It seems persistent notifications work now - at least my testcase works on trunk. Can anybody confirm this has indeed been fixed? Recompiling trunk now, will report back later At last! Finally everything works 100% correctly here. Please backport the fix if possible. |