On Mac Cocoa OS X 10.5, the throbbing default button animation is implemented as a separate thread that calls drawing methods directly from that thread. You would think that this wouldn't be a big deal but threads in a GUI toolkit are always a big deal.
It's an amazing GUI toolkit 101 blooper!
Who cares if the default button is painted from another thread? First off, SWT checks thread accesses to avoid operating system crashes. First attempts at a fix removed this check, causing operating system crashes.
How about hacking so that drawing requests from the throbbing thread are serviced, but don't run any SWT listeners? No good. The Mac user-interface is composited so parents of the button are asked to a paint all the way up to the shell and the button paints last on top of them.
Can't paint ... but must.
It seems that there are only two fixes:
- Lock and allow the throbbing thread to run as the Cocoa Gods intended
- Throb somehow safely in the UI-thread
Since introducing locking everywhere in SWT at Eclipse 3.5 M6 and hoping that it works at this point is insane, all we can do for now is attempt to throb safely. This fix involves remembering that you were asked to throb, telling the operating system that it has throbbed already and then later throbbing with impunity from the user-interface thread.