Apper works really solidly in F18 now, kudos for that! Security updates get installed promptly, and regular updates always install smoothly. Now that basic functionality is achieved, it's time to make the whole thing much more usable. :) First, Apper likes to create notifications for everything it does, and never dismisses or updates them automatically. I'm not sure if KNotify allows notification messages to be updated or dismissed programmatically, but that's the natural way to handle this kind of situation. Hypothetically: - The notification of updates pops up - I click "Install" - Without bringing up any additional popups (e.g. Apper's own UI), the notification changes to: * a progress bar * a 1-3 line description of what's going on (e.g. which packages are currently being downloaded/installed). - If I "dismiss" the notification, I should still see an indication of ongoing activity Anyway, I just want to prompt discussion. In general with KNotify, "Make it more like Android" is a great place to start. :) Reproducible: Always Steps to Reproduce: 1. Wait for a security update and a regular update to come in 2. Accept the regular update 3. Observe the flurry of notifications, some of which don't get dismissed automatically, despite being stale Actual Results: Too many notifications :) Expected Results: Fewer notifications :) I'm setting this as Minor instead of Wishlist, because I consider it a serious usability problem for new users, but I can cope of course. :)
Created attachment 79444 [details] Image of KNotify area after some Apper updates have gone through "Redundant" indicates that the two notifications could be collapsed into one On the other hand, "No distinction" means that we shouldn't have notifications that look the same but signify different infirmation (i.e. one was for the security update, one was for the regular update) "Stale" indicates a notification that is now completely obsoleted by the fact that the regular update has already concluded.
Sorry there only one thing I can do, which is to reuse the existing notification of updates available when more show up. You don't see the code but there are actually two distinct things on that screenshot, notifications and jobs. What sucks is that I can't control what is displayed when a job finished and the systray implementation is also weird as it shows an Open button where I never emmitted a file.. So it's pretty much all plasma bugs.
This seems to have gotten worse recently (apper 0.8.1-2 in Fedora 20). Now every single changelog that is shown through the plasma widget causes a notification that has to be dismissed manually.
I have written a patch[1] that somewhat improves the situation. Would be nice if this was picked up. [1] https://git.reviewboard.kde.org/r/117990/
(In reply to comment #3) > This seems to have gotten worse recently (apper 0.8.1-2 in Fedora 20). Now > every single changelog that is shown through the plasma widget causes a > notification that has to be dismissed manually. Does that happens when the Apper UI is open? Because the interactive bool should be false when the creator of such transaction is open. In the end I might remove every feature that is plasma related as I'm tired of working around Plasma bugs...
(In reply to comment #5) > (In reply to comment #3) > > This seems to have gotten worse recently (apper 0.8.1-2 in Fedora 20). Now > > every single changelog that is shown through the plasma widget causes a > > notification that has to be dismissed manually. > > Does that happens when the Apper UI is open? > Because the interactive bool should be false when > the creator of such transaction is open. It happens when using the plasmoid. Don't know about the main apper UI, I usually do not use it. > In the end I might remove every feature that is plasma related as I'm tired > of working around Plasma bugs...
I'll try to reproduce it, but the fact that the control I have over KJobs regarding how they end up looking on plasma notifications is really bad, so I either don't use them or use them for some really must things, tho it's quite odd that you see them. Can you add a qDebug() and see the interactive before the line you patched? it should be false as the plasma process is still running...
(In reply to comment #7) > Can you add a qDebug() and see the interactive before the line you patched? > it should be false as the plasma process is still running... It seems that "isCallerActive" returns false in the first invocation of TransactionWatcher::transactionChanged, which makes "interactive" true and creates the KJob. It seems to me that the properties of the transaction are not yet loaded when transactionChanged is invoked the first time. Looking at the packagekit-qt source, it seems that TransactionPrivate::callerActive is not even initialized.
(In reply to comment #8) > (In reply to comment #7) > > Can you add a qDebug() and see the interactive before the line you patched? > > it should be false as the plasma process is still running... > It seems that "isCallerActive" returns false in the first invocation of > TransactionWatcher::transactionChanged, which makes "interactive" true and > creates the KJob. > It seems to me that the properties of the transaction are not yet loaded > when transactionChanged is invoked the first time. > Looking at the packagekit-qt source, it seems that > TransactionPrivate::callerActive is not even initialized. Based on what I've found out so far, I have a new suggestion for fixing this: Don't call transactionChanged from watchTransaction in the TransactionWatcher class. When a new transaction appears, watchTransaction creates a new Transaction object, and goes on to invoke transactionChanged, which uses the transaction properties to decide whether to create a KJob. The Transaction constructor loads the properties asynchronously, though, which means they are likely (always?) not there yet when transactionChanged is called from watchTransaction. When the async loading of the transaction properties completes, that triggers a call to transactionChanged via the changed() signal, which then does the right thing.
Created attachment 86810 [details] Patch to TransactionWatcher.cpp as described in comment #9 See comment #9.
Git commit bbf4205a4924e7fe9f67b344af2b345f22fed53f by Rex Dieter. Committed on 05/11/2014 at 16:18. Pushed by rdieter into branch 'APPER_0.8.X'. apperd: Restrict creation of KJobs to the more interesting transaction roles This is essentially a backport of what's already present in master/ branch. REVIEW: 117990 M +7 -1 apperd/TransactionWatcher.cpp http://commits.kde.org/apper/bbf4205a4924e7fe9f67b344af2b345f22fed53f
Oh boo, I didn't notice the latest patch here, and committed what was in reviewboard, after testing that it worked as advertised... and seemed to match the logic already present in apper master/ branch. Feel free to re-open if a different appoach should be taken.