GUI Decision: Progress in Status Bar vs Dialog
June 20, 2008 at 16:11 | In Perl, Summer of Code | Leave a CommentTags: gsoc2008
I have been working on an algorithm to sort various data (installed modules, updated modules, etc.) into different categories, as it is on http://search.cpan.org. Since CPANPLUS::Module does not have a ‘chapterid’ section, I have had to write my own method to sort data into the 27 different categories, called ‘chapters’. This ‘chapterid’ information is stored in a file called 03modlist.data.gz. Since CPANPLUS DOES download the file, i can read the already downloaded file’s contents, which is nothing more than an array reference with all the data I need. Then I sort the data into the different categories. This was fairly easy.
Then came the difficult part. It takes a long time, about 3-5 minutes, to sort the data into categories, then another 2 or 3 minutes to populate the wxTreeCtrl with the data. So I needed a way to communicate to the user what’s going on. Initially, the whole UI would freeze while all this sorting was taking place. So I looked into a few solutions for this:
Solution 1: Threads
I immediately thought about threads, because I like to use them when i can. They are a great feature if what you’re doing doesn’t depend on anything else. I read quite a bit about Perl’s thread support, and found out that it works best if the Perl Modules you are using also support threads. Wx has its own thread support through the Wx::Thread class. I tried both Wx’s and Perl’s threads,and they both worked equally well. They solved the initial problem (both with object access warnings), but nothing was telling the user what was going on, and I didn’t want the user to sit there wondering what was happening for eight minutes, so I needed something more.
Solution 2: wxStatusBar
I tried updating the main window’s Status Bar with and without threads. Without threads, the UI wouldn’t even display anyhting. With threads, the Status bar worked, but the UI worked sporadically, as the Status Bar’s text was updated, which was quite frequently. So I shortened the update, which, to my dismay, did not solve the sporadic UI problem. Also, I noticed about a 33% increase in the time it took to sort all those modules. I did not want this. I needed something that would tell the user what was happening, and not freeze the UI.
Solution 3: wxProgressBar or wxProgressDialog?
Finally, I looked into using a ProgressBar. Wx has two flavors of progress bars: a single progress bar that you can use in any window, or a Dialog Box with a progress indicator. This was a design decision that was quite difficult to make. Should I use a wxProgressDialog, or put a wxProgressBar right in to the main window? Since the user isn’t really supposed to do anything while the sorting is taking place, I decided on a wxProgressDialog. Programmatically, it is easy to use and doesn’t require a redesign of any windows. It has all the functionality i needed: A progress bar and text to let the user know what’s going on. (That’s all the features a wxProgressDialog has.) Whe I tested it, I was amazed! I expected the main window to freeze, like before, and the dialog to update accordingly, but, to my surprise, the main window did not freeze. I also expected the sorting time to decrease substantially, because of all the progress bar updates, but the decrease was negligible. I took out all the threading code at first, because I did not know how the progress dialog would respond to threads. As it turns out, threads were unneccessary.
Overall, this experience was very educational, both for the Wx widget set and for Perl’s threading support. I am still having sorting issues, but at least the user has something to look at while she waits!
Look for my Week[3] report in the next couple of days!
No Comments Yet »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Blog at WordPress.com. | Theme: Pool by Borja Fernandez.
Entries and comments feeds.