Bug 485796 - Kpackagekit update window disappears if different window is selected.
Kpackagekit update window disappears if different window is selected.
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kpackagekit (Show other bugs)
10
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Steven M. Parrish
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-16 15:11 EST by TR Bentley
Modified: 2009-04-21 21:05 EDT (History)
9 users (show)

See Also:
Fixed In Version: 4.2.2-2.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-21 21:05:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 177154 None None None Never
KDE Software Compilation 184236 None None None Never

  None (edit)
Description TR Bentley 2009-02-16 15:11:34 EST
Description of problem:
Since upgrading to KDE 4.2 KPACKAGEKIT pops up with details of changes.  It gives 3 options but it you click on another window the pop up goes.  Updates then have to be added by started KPackageKit from the menu.


Version-Release number of selected component (if applicable):
Latest version 

How reproducible:
Happened 3 times.  After each update.

Steps to Reproduce:
1.
2.
3.
  
Actual results:
Lost window

Expected results:
window stays present to user can select options

Additional info:
Comment 1 Kevin Kofler 2009-02-17 00:45:30 EST
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?
Comment 2 Ville Skyttä 2009-04-16 12:50:03 EDT
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.
Comment 3 Rex Dieter 2009-04-16 13:20:12 EDT
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
Comment 4 Rex Dieter 2009-04-16 13:26:10 EDT
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?
Comment 5 Kevin Kofler 2009-04-16 13:32:54 EDT
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).
Comment 6 Kevin Kofler 2009-04-16 13:33:51 EDT
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.
Comment 7 Steven M. Parrish 2009-04-16 13:50:03 EDT
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
Comment 8 Rex Dieter 2009-04-16 14:51:41 EDT
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)
Comment 9 Kevin Kofler 2009-04-16 16:10:03 EDT
> (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.
Comment 10 Kevin Kofler 2009-04-16 16:12:06 EDT
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!
Comment 11 Fedora Update System 2009-04-17 14:05:30 EDT
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
Comment 12 Fedora Update System 2009-04-21 21:05:39 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.