Bug 213820

Summary: pirut doesn't update ui during long yum operations
Product: [Fedora] Fedora Reporter: Ray Strode [halfline] <rstrode>
Component: pirutAssignee: Jeremy Katz <katzj>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: jensk.maps, kengert, wwoods
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-09-11 18:23:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
delegate blocking calls to helper threads
none
convienence class to hide the murky details none

Description Ray Strode [halfline] 2006-11-03 06:45:47 UTC 
Right now when running pirut, it blocks the UI while doing I/O.  Previously the
solution for this was going to be to rely on the composition manager to make
invalidated regions automatically redraw.  Now that we're using compiz, that's
not really a good idea (because compiz will slowly desaturate and fade out a
window that isn't responding to window manager pings, and because since we're
shipping compiz we'll always have to ship metacity without a compositor.

So I spent the last three days of train rides to and from work and the thursday
night hackfest today coming up with an initial patch to make things better. 
It's not super-tested but it seems to mostly work.
Comment 1 Ray Strode [halfline] 2006-11-03 06:45:47 UTC 
Created attachment 140217 [details]
delegate blocking calls to helper threads
Comment 2 Ray Strode [halfline] 2006-11-03 06:48:26 UTC 
Created attachment 140218 [details]
convienence class to hide the murky details

you'll also need the above patch to rhpl for things to work
Comment 3 Ray Strode [halfline] 2007-05-03 12:06:25 UTC 
You know, I've been thinking about it a bit and maybe a better solution than
finishing up these patches would be to offload all the work to yum-updatesd. 
That way even if the app crashes or X gets killed the update will continue and
not hose the database.  So I think it would be something like yum-updatesd does
all the heavy lifting, pup just shows a view of yum-updatesd and pirut works as
a remote control into yum-updatesd as well as being a view itself.

Both pup and pirut would only make non-blocking d-bus calls to talk to the
updatesd daemon, so they would always properly redraw.
Comment 4 Jeremy Katz 2007-09-11 18:23:16 UTC 
We should now update as much as is possible without either a) threading or b)
switching to multiple processes.  Threading introduces some fun problems with
sqlite and multiple processes is a whole different ball game so neither is
immediately on the hit list.

If you hit places where we aren't refreshing, file specific bugs about them and
I'll see about making sure all the proper callbacks are occurring (and see about
adding more if needed)