|
|
Guidance in custom patch development I'm working on a custom patch, to receive interactivity from TUIO external applications. I would like to implement it with a behaviour similar to interaction patch, with the that upper dot, near to the title, to connect to a specific sprite or billboard, which will enable me to create much cleaner compositions then parsing incoming UDP in a TUIO patch and then, iterating and javascripting sprites and billboards to figure out which one is the current UI to work on. Don't think this will be dificult, but the thing is, i don't find in anywhere any documentation regarding to the use of this new QC 4.0 functionality presented in Interaction patch, in custom plugins. Does any one in the forum, able to hack or knows a place in which I can find documentation to implement such behaviour in custom plugins?
|
Yes. The interaction functionality is private. 3rd party plugins do not get it, which really breaks the whole concept of having a 3rd party renderer or plugin at all.
You can probably use the Kineme Skank (reverse engineered private API) to get an interaction port on a plugin patch, but I dont know specifically if its possible via Kineme Skank API, as I use the public API, even though its in many ways less useful.
It's not possible to access the Interaction port via the public QC API, as @vade mentioned.
In the private API, the QCPatch class has the following class method:
which I presume is what you'd override to get an Interaction port.
...but other than that we at Kineme haven't really examined QC Interaction.
It may also be possible to conceive your patch in a slightly different way, and/or introduce a processor patch that allows interaction.
Interaction is sort of a hit test, where mouse down allows grabbing of the object and update of the current position to hit test. One can use regular QC patches to emulate interaction using a couple (or more?) different approaches. I don't know if that's viable or not for you. I needed to put it together so that I could have other hardware besides a trackpad/mouse "do" interaction.
I kind of petered out on this attachment... the offset ports aren't iterator safe, and I see you mention something about needing to use an iterator. I didn't need the iterator functionality, so I didn't spend time on getting that working.
I'm posting it because it demonstrates what I mean about not needing to use Interaction ports to get interaction type behavior. I've seen some other clever approaches to interaction that test for pixel color. It might be helpful to search, because someone may have made a workaround that works for you.
That said, please don't take that as any suggestion not to forge ahead in getting an interaction port going. That would be cool indeed.
I will definitely take a look at the API :) Thanks for the directions... Where do i download it?
Yes! I will look at it, thanks for the directions...!
George, first of all i'm an admirer of yout work! Thanks for your time and example, and yes i do my thing with iterators, because i need a dynamic number of elements. Updating a structure to render more windows in this particular case. I was successful doing so, but the composition become a mess, with piles of patches. I'm investigating a more simple and elegant way, and coding the patch sounds a better approach to me. I will post the progress here, as soon i get used with that API mentioned here, the "skank". I'm new to objective-c development, will be an iteresting challenge ;)