|
|
mouse events crapola What is with the horribly broken mouse events in SL? At first I thought it was just QC, but now I'm afraid it's just part of SL. There was a serious lack of critical thought process or consideration of many use scenarios with the mouse events change. I've filed a bug on this already and was a little "ho-hum" about it, but I'm starting to realize how horrible it really is as I try to do a few things I was pulling off in QC3. Does there look to be any way to workaround this? Let me know if anyone is finding docs. I think that some of Apple's own example code is falling prey to this as well, but I have to reconfirm (sorry to wantonly throw that out there without the code... I'll dig out the Xcode project, it just doesn't come to mind at the moment). Imagery pops back onto the screen out of nowhere after it gets "locked" outside of the Viewer window when putting focus on another window (the Editor... or anything else), and then shifting focus back to the Viewer window. It can look really bad. There are a handful of downsides to this. One certainly cannot do anything mouse/track ball related, edit a value on the Editor window, and then expect for the image not to jarringly change when you put focus back on the Viewer window. I'm just hoping this is addressed in the new seed. Not holding my breath.
|
I've done a bit of research into this, and haven't been able to completely isolate the issue. other apps that use +[NSEvent mouseLocation]; don't seem to mind if they're focused or not, but QC does for some reason (and not just the editor, QB as well). I'm still trying to formulate better tests for this so I can file a meaningful bug report. Apple's aware of the issue though (I mentioned it to Troy after someone else noticed issues with QB apps, and he was aware as well).
Did enough research to pin down the approximate location for QC devs to poke at, filed a bug report. hopefully this'll get it addressed soon.... (it's really annoying, and breaks the interaction thing severely)
Great!
It was getting kind of comical last night while trying to do something realllly simple, so I decided to break out Xcode to see if the stock stuff was doing the same, and it was, of course. They (the apps) were all using qtz's as a resources, which totally fits into your observations. I pigeonholed myself into using OpenCL, so I couldn't just flip over to 10.5 to do my editing. (I'm not implying that the apps I was building allowed editing, I just wanted to see if the View window performed the same way.)
i don't know if this will help or not.
it seems to me that if you make a qc xcode project from a xib file the mouse events get forwarded like they should... but if your doing any fancy nswindow stuff or desktop rendering etc.. you will need to override the key window so you can get your mouse events without having to click. this seemed to work for me. i tried the old forward all event masks trick but that didn't work for me in SL. this did however.
not sure if that is the problem your talking about, but it is one i ran into the other day.
QuartzBuilder has that already, and it doesn't fix the problem.
the issue we're referring to has its roots in the Mouse patch -- if we made our own, we could work around it. (I did a primitive version of that just to see if the information was getting passed to the composition -- it is, so it's the Mouse patch that's not handling it correctly under certain situations.)
Essentially, what's happening is the Mouse patch notices when the QCView (or the view that a QCRenderer is rendering to) isn't focused, and when it's not, it stops honoring mouse location events. For other events, this is an ok thing to do (skipping Key presses and mouse clicks when you can't possibly receive them because you're not focused won't cause any problems), but the mouse location isn't an event -- it applies whether the view is focused or not.
ok, yeah this is what was going on with me a few backs with QB. once i switched focus to the finder the mouse positions stopped working. so yeah i actually didn't test the key window override while not focused on the app. i was having problem just getting the coordinates into my fullscreen window while the app was focused.
well its good you made a quick mouse patch to test with, i was driving my self crazy trying to figure out how to get the mouse to work with the app focused in full screen mode. i could just see myself spending hours trying to figure out this problem never thinking it could be the apple mouse patch. hopefully you'll get some feedback from apple.
seems like a serious problem if you ask me. i like to make art with qc and stuff so its not that big of deal for me, (or well priority for me right now) but if i where using qc to develop applications and what not this would defiantly bug me. no intended pun on the word bug.
I filed a bug report on this as well, but I'm really glad that you tracked it down to the actual patch. That's pretty heartening.
I have some other issues (not as much functional, as much as that I think things "shouldn't" work how they do) when it comes to Editor/Patch Inspector and what you can/can't do when you put a patch on the Editor, depending on where focus was last - copy not being grayed out, so I can "copy" with the patch actually selected (with the little highlight ring around the patch), yet it doesn't really copy. I can put a patch on the Editor, yet not be able to "undo" without putting focus on the Editor. Eh. I realize I could nitpick it to death, but I'd rather watch some C.Y.E that someone is playing on TV right now :)