I will point out that a fundamental part of the image filter protocol in QC is that published xy automatically receive mouse events in the editor without even hooking anything up, at least for many major versions, possibly still. That’s one better than even having to load and connect the QC mouse patch. And if you wanted to manually, you could, of course. Mouse, and other forms of hardware interaction that need to get info about the output window coordinates, are pretty fundamental to the concept of an interactive programming environment. IMO. Just making an argument for it and against the hypothesis that it doesn’t fit.
You all have done such a great job in general, but every so often, the typical useful defaults and use cases that were easily available in QC just are not here. I think maybe I coincidentally stumble on those a lot :)
There are so many different mouse related patches and if one one of them did what the one in QC did, it would eliminate the need for all of the linking together stuff. Or maybe some kind of subcomposition that could work similarly.
What I can't figure out is how to get the mouse coordinates normalized to the render window, WHEN the composition is setup as an image filter protocol. As far as I can tell, when it's in that format, there is no way to get info from the output window, which apparently is required in order to setup something like the QC mouse patch.
Is there an example composition that shows mouse x/y and left click, interacting with a shader toy node, when it's in image filter format?
I am having a little trouble getting the coordinates normalized to the window as opposed to screen. I'm also not 100% sure that "Mouse Is Pressed" and "Mouse Position" are working inside of the shader toy node as iMouse.z, and iMouse.xy, respectively.