I, for one, am glad that Dick brought up the issue. I'd been having an odd problem where having eclipse stop at a breakpoint in my swing application caused my *entire* *desktop* to stop responding to all input. The only solution was remote SSH and kill the swing app being debugged.
I haven't experienced this problem again since setting GDK_NATIVE_WINDOWS=1 before starting eclipse. Coincidence? Maybe, but I'm glad the Posse gave me the idea, because the trouble was having was driving me nuts! Besides, it didn't sounds like "SWT Bashing" to me. It sounded like they were reporting and the usual pissing contest one might expect as to who was more at fault when a change in a library causes a library client to misbehave. Not that it matters to an end-user. I found the GDK argument that it's all fine because you can just set an environment variable to work around the problem somewhat hollow. Sure, that might be find for developers who can be expected to know what the hell an environment variable is, but ... what about normal users? On the other hand, the observation that this change only seemed to effect SWT apps indicates that SWT must be doing something with the GDK APIs that no one else has thought to do. Possibly something inadvisable, wouldn't you agree? What's infuriating about this particular bug, whatever the proximate cause, is how utterly in-transparent the symptoms are. I mean, a crash and a stack dump would be better than just having the entire desktop interface randomly stop responding to input. For my POV both teams deserve some lumps for this one. I'm glad it was mentioned on the podcast. I'm hopeful it won't be an issue in the future and I'm glad I have an easy workaround for the interim. // Ben -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
