Bug 213820 - pirut doesn't update ui during long yum operations
Summary: pirut doesn't update ui during long yum operations
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: pirut
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-11-03 06:45 UTC by Ray Strode [halfline]
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-09-11 18:23:16 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
delegate blocking calls to helper threads (8.87 KB, patch)
2006-11-03 06:45 UTC, Ray Strode [halfline]
no flags Details | Diff
convienence class to hide the murky details (6.44 KB, patch)
2006-11-03 06:48 UTC, Ray Strode [halfline]
no flags Details | Diff

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)


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