SharpDevelop execute many tasks that require progress reporting. Most also can be cancelled by the user.
- Loading a solution (parsing files for code completion and class browser)
In SharpDevelop 184.108.40.20683, I've rewritten the IProgressMonitor interface used for these operations. The main difference in comparison with the old interface is that it is now possible to create nested progress monitors, allowing the composition of large progress-reporting operations from many smaller operations. Also, creating nested progress monitors now allows to safely report progress from parallel computations. Every thread can create its own nested progress monitor for reporting its progress.
Now what happens with these progress reports? They will be collected by the ProgressCollector class. The ProgressCollector takes care of summing up the progress from all nested progress monitors. It also handles the multi-threading issues. The output of a ProgressCollector is a simple set of properties describing the current progress of the operation, plus a "PropertyChanged" event which will be fired only on the GUI thread. This allows using WPF data binding to display the total progress in a progress bar.
Another difference is that the cancellation support has been simplified by making use of the .NET 4 cancellation framework.
The above changes don't have any visible effect for the end-user. However, while working on this, I had an idea: similar to the progress bar in Windows Explorer in Vista and Windows 7, the progress bar should turn red when there are errors. This gives immediate visual feedback that the build failed, making it a lot less likely that you miss the error messages in the "Errors" pad and wonder why your binary didn't change.
A related change in SharpDevelop 220.127.116.1190 is that the progress is now shown on the Windows 7 task bar:
So the progress of long-running builds is always visible; even if you minimize SharpDevelop and do something else while the compiler is working.