🚀 go-pugleaf

I have a Swing desktop application that is currently written without any 
explicit thread creation.  Most of the operations that the program 
performs are quite simple and take little time.  However, there is an 
operation that can be rather lengthy -- on the order of 5 seconds, but 
with complex data it might run up to 20 or 30 seconds.

Currently, the GUI is pretty much dead while this operation is ongoing.  
The fact that it does not respond to user input is a concern, but it is 
not critical since there is little that the user would be allowed to do 
while this is running.  However, it would be useful to give the user the 
option of canceling.

But my primary concern is that the GUI does not _look_ like it is doing 
anything.  To solve this problem, I would like to show a ProgressMeter 
while the operation is performed, but I am not sure of the best way to do 
this.  I am hoping that the solution will also provide the capability of 
canceling the operation.

The ProgressMeter / ProgressMonitor examples I have seen all perform the 
long task in a separate thread, and my application currently does all of 
its work in the event-dispatch thread.  I am concerned that moving this 
work to a separate thread may cause problems.

The application uses a Model-View architecture.  The Swing view 
components are registered as listeners on the model objects, which use 
javax.swing.event.EventListenerList for registering listeners and firing 
events.  All GUI updates are triggered through changes to the model.

The long operation perform extensive modifications of the model, which 
results in many events fired at the Swing view components, which causes 
these components to change their appearance, create some new components 
and remove others, etc.  This works fine, since it is all happening from 
the event-dispatch thread.  But if I were to create a separate thread to 
perform the operation, this would violate the Swing single-thread rule.

Does anyone have any comments or suggestions as how to deal with this?

-- 
John P. McGrath
<mcgrath@enter.net>
<jpm@nscs.fast.net>