frame method of NSWindow returns some client-side value, which is updated when the window receives events notifying it that it has been moved or resized. Which is all very well, but it seems that if you move the window around while it is not responding, then the frame method returns the old value! This is absurd.It means that for example if you reload some files in the Factor UI listener, which then causes a 10-second recompile, during which you move the window, then mouse handling is completely screwed up after Factor starts responding again.
Does anybody know if there is a way to query the window system for the window's actual location?
Update: This only happens under certain circumstances. Very weird. I'll try to narrow it down.
Update 2: Actually it is pretty easy to reproduce. Start Factor and type
30000000 [ ] times (or anything else which takes several seconds to run). Then move the listener window around for a few seconds, then switch to another application. When Factor is done, switch back, and it will not respond to clicks because it will think the mouse location is different than what it actually is.
2 comments:
I don't know about Factor's internals, but is there a reason why computation can't happen in a background thread (and you could use distributed objects or invokeInThread: (or what's it called) to have the Factor core communicate with the GUI, I think)?
Because Factor won't support native threading until 2.0.
Post a Comment