GNOME Bugzilla – Bug 564294
Give some indication of activity in the 'open file' window
Last modified: 2009-03-11 04:04:53 UTC
By default, when you click "Open Source File...", it tries to read the list of source files from the executable being debugged. If the executable is very large (for example, mozilla), this list of files can be huge and it can take quite a while to parse and populate the treeview. There is no indicatino that anything is happening whiel we do this. It would be nice if we could show the user that something is happening in one of several ways: a. add items to the list as we parse them (e.g. don't wait for all files to be parsed and then add them all at once) -- I dont' know whether this is technically feasible or not b. when the window opens, add a single item to the treeview that says something like "Loading list of files from the executable..." and then remove it when we're done loading the files and add the files to the treeview. c. add a pulsating progress bar to the window somewhere d. better ideas?
Created attachment 130181 [details] [review] Add a simple status label to the file list widget (basically option b)
Comment on attachment 130181 [details] [review] Add a simple status label to the file list widget (basically option b) hm, aparently this patch makes it so that scrolling through the file list with the keyboard no longer scrolls the treeview automatically. I guess I need a slightly different approach.
Created attachment 130248 [details] [review] Improved patch. this one works with keyboard navigation again
pushed
Hey, Thanks for this interesting patch. I was thinking, maybe we can think of exposing an API that would signal progress during the GDBMI parsing ? (assuming it's the parsing that takes time, and that has to be proved). Or more generally, it would be nice to think of an architecture of APIs that allows us to show the progress of what we are doing. It would have to be linked to bug #548124, I guess.
Yes, I think it would be quite nice to have some sort of progress api. I did do some experimenting when working on this bug: I added a progress bar to the 'open file' dialog, with a .1s timeout callback that just called progressbar->pulse(). Currently, this timeout handler never gets called because the parser is blocking the timeout handler from running. However, as a quick hack, I modified the function parse_file_list() by adding several calls to Glib::MainContext::get_default()->iteration(false); after each file was parsed (and in several other places throughout that function). After that, the progress bar pulsed perfectly. So I think it's fairly safe to say that it is the time spent parsing that is actually blocking the UI. Obviously my experiment was a quick and ugly hack, but I think that it points to the fact that we need a solution for this sort of thing. That is what prompted my email to the mailing list about cpu-intensive tasks.