Bug 177154 - Plasma notification style ignores some parameters in KNotification::event
Summary: Plasma notification style ignores some parameters in KNotification::event
Status: RESOLVED FIXED
Alias: None
Product: plasma4
Classification: Plasma
Component: notifications (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Rob Scheepmaker
URL:
Keywords:
: 180871 181119 183084 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-12-07 17:29 UTC by Dario Freddi
Modified: 2009-04-28 18:26 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dario Freddi 2008-12-07 17:29:41 UTC
Version:            (using Devel)
OS:                Linux
Installed from:    Compiled sources

New KNotify plasma style has some bugs in detecting parameters streamed through KNotification::event(). The following code used to work as expected with old notifications:

KNotification::event(evid, message, KIcon(iconname).pixmap(20, 20),0, KNotification::Persistent, d->applicationData);

Now, custom name and icon are not set; but much worse is the fact that the notification is not made persistent. This leads Powerdevil to behave incorrectly when the user requested to wait x seconds before suspending, since the notification gets closed anyway.
Comment 1 Diederik van der Boor 2008-12-21 23:25:21 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.
Comment 2 Dario Freddi 2008-12-27 18:14:53 UTC
Reassigning the bug
Comment 3 Rob Scheepmaker 2009-01-06 15:28:14 UTC
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.
Comment 4 Mehrdad Momeny 2009-01-10 18:45:47 UTC
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 :-/
Comment 5 Rob Scheepmaker 2009-01-13 19:11:58 UTC
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?
Comment 6 Dario Freddi 2009-01-13 19:46:56 UTC
It fixed icon & application name, though the issue with the persistent flag still persists (sorry for the bad joke -.-)
Comment 7 Rob Scheepmaker 2009-01-13 21:36:57 UTC
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?
Comment 8 Dario Freddi 2009-01-13 21:58:21 UTC
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.
Comment 9 Rob Scheepmaker 2009-01-17 18:13:29 UTC
Any follow up on this? Does it work when specifying persistent in the notifyrc?
Comment 10 Dario Freddi 2009-01-17 18:20:53 UTC
Now it gets all parameters correctly. I'll try with persistent now and report
Comment 11 Dario Freddi 2009-01-18 11:54:03 UTC
*** Bug 181119 has been marked as a duplicate of this bug. ***
Comment 12 Dario Freddi 2009-01-18 12:49:47 UTC
*** Bug 180871 has been marked as a duplicate of this bug. ***
Comment 13 Dario Freddi 2009-01-19 20:27:39 UTC
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.
Comment 14 Dario Andres 2009-02-21 03:19:57 UTC
*** Bug 183084 has been marked as a duplicate of this bug. ***
Comment 15 Rob Scheepmaker 2009-04-09 17:31:23 UTC
@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...
Comment 16 Dario Freddi 2009-04-09 19:27:00 UTC
@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.
Comment 17 Rob Scheepmaker 2009-04-09 19:40:56 UTC
@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.
Comment 18 Olivier Goffart 2009-04-12 16:24:00 UTC
From my debug, the popup just disapears in plasma. And KNotify is not even aware the popup has been closed.
Comment 19 Rob Scheepmaker 2009-04-15 14:59:53 UTC
@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?
Comment 20 Michael Leupold 2009-04-26 19:42:34 UTC
It seems persistent notifications work now - at least my testcase works on trunk.
Comment 21 Rob Scheepmaker 2009-04-27 18:03:15 UTC
Can anybody confirm this has indeed been fixed?
Comment 22 Dario Freddi 2009-04-27 18:13:06 UTC
Recompiling trunk now, will report back later
Comment 23 Dario Freddi 2009-04-28 18:26:24 UTC
At last! Finally everything works 100% correctly here. Please backport the fix if possible.