Bug 485796

This looks like an issue with the new Plasma notifications.

If you put this in your ~/.kde/share/config/plasma-appletsrc:

[AppletGlobals][plasma_applet_systemtray]
ShowJobs=false
ShowNotifications=false

(you may have to "kquitapp plasma" first and restart "plasma" after the edit), all problems with lost notifications (also progress reports for file transfers timing out before the transfer is complete) should be gone. The look&feel for the notifications will be the old KDE 4.1 though (popups in the top right of the screen for notifications, dialog boxes for the progress dialogs), not the new notification system.

Are we really sure we don't want this as the kde-settings default?

I'm not sure if this is the same bug, but the kpackagekit tray icon only shows up when it is checking for updates for me, after it it disappears even if there are updates available.  I tried the recipe in comment 1 but it does not appear to make any difference.  This is with kde 4.2.2, qt 4.5 from current F-10 updates-testing.  (If this is not the same issue as the reported one, let me know and I'll file another bug report.)

Just curious, is it intended that the recipe in comment 1 sets those Show* values to false?  Without knowing anything about this, true would sound more natural.

Interestingly, I tried the workaround awhile back, and it didn't seem to work for me... but just did again, and now it does.

The old-style notifications are certainly not nearly as nice looking, but at least they don't vanish either.

I'll work to make the older, non-beautified, but more-reliable notifications the default, and we'll probably want to ReleaseNotes that for folks who want to disable it.

For posterity, other related links:
http://userbase.kde.org/Plasma
http://aseigo.blogspot.com/2009/01/todays-tip-turning-off-fancy-schmancy.html

Alternatively, make kpackagekit not use (just) notifications, but make it's systray applet persistent/visible when updates are available. 

SMParish, 
is something like that doable?
Don't have my rawhide box here handy, does kpk-0.4 handle this better or differently?

IMHO, the notifications need to be fixed, KPackageKit isn't the only victim of the current state of the fancy Plasma notifications. AFAIK it'll be better in 4.3, we should just disable them in 4.2 (in fact I've been advocating for that ever since we pushed 4.2.0 as an update and I have them disabled on my systems).

Alternatively, we could scan trunk for Plasma notification fixes and backport them. But given F11's freeze status, that may be pretty risky for F11.

yes it should be possible to keep the icon in the system tray as long as there are pending updates.  will get with upstream and see if we can get this in soon.

steven

From chatting in #plasma, looks like this is a plasma bug, in that peristent notifications should remain (with an "(I)" symbol) in notification area.  Except, that they don't.

(Oh, and we'd get brutally flamed for using old-style notifications to workaround it)

> (Oh, and we'd get brutally flamed for using old-style notifications to
> workaround it)

I don't give a darn, the new ones are not ready for production use, they should never have been enabled by default, reverting to the working ones should have been done already, it was a mistake to wait so long.

Maybe in KDE 4.5 or 4.6 we can consider the new ones again.

My position: the more they flame us, the longer we should keep the old ones out of spite.

PS: The Plasma folks flamed us for shipping panel autohide when they considered it not ready yet, but then they want to flame us if we don't enable their broken Plasma notifications which are a lot more buggy than the panel autohide backport ever was? Hypocrisy!

kdeutils-4.2.2-2.fc10, kdetoys-4.2.2-2.fc10, kdesdk-4.2.2-2.fc10, kdeplasma-addons-4.2.2-2.fc10, kdeedu-4.2.2-1.fc10, kdebase-4.2.2-2.fc10, kdeartwork-4.2.2-3.fc10, kdeadmin-4.2.2-2.fc10, kdeaccessibility-4.2.2-1.fc10, sigen-0.1.1-1.fc10, qgit-2.2-4.fc10.1, psi-0.12.1-2.fc10, kde-plasma-weather-1.0.0-3.fc10, arora-0.6-1.fc10, kde-l10n-4.2.2-1.fc10, kdegraphics-4.2.2-3.fc10, kde-i18n-3.5.10-4.fc10, kdepimlibs-4.2.2-3.fc10, oxygen-icon-theme-4.2.2-1.fc10, kdebindings-4.2.2-2.fc10, kdepim-4.2.2-3.fc10, konq-plugins-4.2.2-1.fc10, kdemultimedia-4.2.2-2.fc10, kdenetwork-4.2.2-1.fc10, kdegames-4.2.2-6.fc10, kdelibs-4.2.2-5.fc10, qjackctl-0.3.3-3.fc10, qsynth-0.3.3-4.fc10, kdebase-workspace-4.2.2-3.fc10, qt-4.5.0-14.fc10, kdebase-runtime-4.2.2-4.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kdeutils kdetoys kdesdk kdeplasma-addons kdeedu kdebase kdeartwork kdeadmin kdeaccessibility sigen qgit psi kde-plasma-weather arora kde-l10n kdegraphics kde-i18n kdepimlibs oxygen-icon-theme kdebindings kdepim konq-plugins kdemultimedia kdenetwork kdegames kdelibs qjackctl qsynth kdebase-workspace qt kdebase-runtime'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3389

kdeutils-4.2.2-2.fc10, kdetoys-4.2.2-2.fc10, kdesdk-4.2.2-2.fc10, kdeplasma-addons-4.2.2-2.fc10, kdeedu-4.2.2-1.fc10, kdebase-4.2.2-2.fc10, kdeartwork-4.2.2-3.fc10, kdeadmin-4.2.2-2.fc10, kdeaccessibility-4.2.2-1.fc10, sigen-0.1.1-1.fc10, qgit-2.2-4.fc10.1, psi-0.12.1-2.fc10, kde-plasma-weather-1.0.0-3.fc10, arora-0.6-1.fc10, kde-l10n-4.2.2-1.fc10, kdegraphics-4.2.2-3.fc10, kde-i18n-3.5.10-4.fc10, kdepimlibs-4.2.2-3.fc10, oxygen-icon-theme-4.2.2-1.fc10, kdebindings-4.2.2-2.fc10, kdepim-4.2.2-3.fc10, konq-plugins-4.2.2-1.fc10, kdemultimedia-4.2.2-2.fc10, kdenetwork-4.2.2-1.fc10, kdegames-4.2.2-6.fc10, kdebase-workspace-4.2.2-3.fc10, qt-4.5.0-14.fc10, kdebase-runtime-4.2.2-4.fc10, qjackctl-0.3.4-1.fc10, qsynth-0.3.3-6.fc10, kdelibs-4.2.2-7.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.