Bug 262742

Summary: When an error occurs dialogs are shown both in software updates and Muon at the same time
Product: [Applications] muon Reporter: Alvaro Manuel Recio Perez <amrecio>
Component: libqaptAssignee: Jonathan Thomas <echidnaman>
Severity: minor Keywords: triaged
Priority: NOR    
Version: 0.2   
Target Milestone: ---   
Platform: Unlisted Binaries   
OS: Linux   
Latest Commit: Version Fixed In:

Description Alvaro Manuel Recio Perez 2011-01-10 11:33:54 UTC
Version:           0.2 (using KDE 4.5.95) 
OS:                Linux

When the software updates and the regular Muon interfaces are both open and an error occurs while trying to update a package two error dialogs are shown, one for each instance of the program. The second (and perhaps unnoticed) error dialog may confuse the user.

Reproducible: Always

Steps to Reproduce:
1. Prepare the system somehow so an update will generate an error.
2. Open the software updates mode of Muon by clicking the update notification.
3. Open regular Muon.
4. In either window, try to update the system.

Actual Results:  
Two error report dialogs are shown, one for each instance of Muon.

Expected Results:  
Only the application from which the user initiated the update should show an error report dialog.

OS: Linux (x86_64) release 2.6.35-24-generic
Compiler: cc
Comment 1 Jonathan Thomas 2011-01-21 01:21:50 UTC
Git commit 0c97ec7521dde286c059cc1da633a91c9ba09071 by Jonathan Thomas
Pushed by jmthomas into branch master

Only listen for signals from the worker if we requested a worker action ourselves by keeping track of when we have requested the worker and only connecting these signals when the worker has a) appeared and b) we requested it. This is a somewhat major behavioral change, so I will not backport it to the 1.1 branch for fear of causing regressions.

Due to a lack of foresight when I originally designed the worker/backend mechanism, I failed to design a way for the backend to be notified about things it requested. Instead the backend gets sent signals indescriminately over DBus that any other application using a QApt::Backend could trigger.
For QApt2 I plan on having the worker functions return a unique DBus object responsible for sending/recieving signals for a particular transaction.

M  +33   -15   src/backend.cpp     

Comment 2 Jonathan Thomas 2011-01-25 01:49:41 UTC
Git commit 7b35c567a7754c8e40ced32d5bb4615974eead8a by Jonathan Thomas.
Pushed by jmthomas into branch 'master'.

Revert "only connect to worker signals when we've requested it" changes. It's too difficult to determine when to connect, causing a ton of regressions.
This will just have to be addressed in QApt2, when the time is right for that. In the meantime, this issue is just a bit annoying.


M  +14   -35   src/backend.cpp