After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 564294 - Give some indication of activity in the 'open file' window
Give some indication of activity in the 'open file' window
Status: RESOLVED FIXED
Product: nemiver
Classification: Other
Component: general
trunk
Other Linux
: Normal normal
: ---
Assigned To: Nemiver maintainers
Nemiver maintainers
Depends on:
Blocks:
 
 
Reported: 2008-12-12 19:30 UTC by Jonathon Jongsma
Modified: 2009-03-11 04:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add a simple status label to the file list widget (basically option b) (3.84 KB, patch)
2009-03-06 06:17 UTC, Jonathon Jongsma
needs-work Details | Review
Improved patch. this one works with keyboard navigation again (4.74 KB, patch)
2009-03-07 20:36 UTC, Jonathon Jongsma
committed Details | Review

Description Jonathon Jongsma 2008-12-12 19:30:27 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?
Comment 1 Jonathon Jongsma 2009-03-06 06:17:28 UTC
Created attachment 130181 [details] [review]
Add a simple status label to the file list widget (basically option b)
Comment 2 Jonathon Jongsma 2009-03-07 05:55:44 UTC
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.
Comment 3 Jonathon Jongsma 2009-03-07 20:36:32 UTC
Created attachment 130248 [details] [review]
Improved patch.  this one works with keyboard navigation again
Comment 4 Jonathon Jongsma 2009-03-10 03:14:26 UTC
pushed
Comment 5 Dodji Seketeli 2009-03-10 07:48:34 UTC
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.
Comment 6 Jonathon Jongsma 2009-03-11 04:04:53 UTC
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.