mmm , i just found the QCpatchcontroller to be pretty handy for binding through InterfaceBuilder>
Maybe i just need to be more confident with code bindings >>>
1 point for QCPatchcontroller : the qc patch is "baked" inside, thus not apparent directly into the bundle.
How would you "hide" the QTZ when using a QCrenderer ?
when binding a QTZ to a QCrenderer, the QTZ has to be present in the bundle (or somewhere on the disk). Hence inspecting the final app's package content will lead you to the original QTZ - which, sometimes -and for obvious reasons - is not what you want.
Using a QCPatchController with conjunction to a QCViews, allows to "hide" the original QTZ into the NIB file.
You can get around that very easily, using [QCComposition compositionWithData:(the data from the .qtz file)]. The .qtz can be embedded in the code this way, or you can encrypt it or whatever.
Not to mention that embedding a qtz in a plist (or nib, which is essentially the same) is trivial to extract. Encrypted compositions are more difficult to extract because it has to be done at runtime (still possible via a debugger, but much more difficult to do overall)
i don't think so. Why you want to do this? Attach the QCRenderer (by code) to an NSOpenGLView or a Custom(GL)view.
Honestly i've never had to use the QCPatchContoller to get bindings to work. QCPatchController is really opaque and not helpful in many ways.
I'd say use a QCCompositionParameterView and just bind to the renderer directly. Its not bad, and it works.
mmm , i just found the QCpatchcontroller to be pretty handy for binding through InterfaceBuilder> Maybe i just need to be more confident with code bindings >>>
1 point for QCPatchcontroller : the qc patch is "baked" inside, thus not apparent directly into the bundle.
How would you "hide" the QTZ when using a QCrenderer ?
i have no idea what you mean. Can you be specific in your setup and what you want to do?
when binding a QTZ to a QCrenderer, the QTZ has to be present in the bundle (or somewhere on the disk). Hence inspecting the final app's package content will lead you to the original QTZ - which, sometimes -and for obvious reasons - is not what you want. Using a QCPatchController with conjunction to a QCViews, allows to "hide" the original QTZ into the NIB file.
You can get around that very easily, using [QCComposition compositionWithData:(the data from the .qtz file)]. The .qtz can be embedded in the code this way, or you can encrypt it or whatever.
i guess i'll have to encrypt then
Not to mention that embedding a qtz in a plist (or nib, which is essentially the same) is trivial to extract. Encrypted compositions are more difficult to extract because it has to be done at runtime (still possible via a debugger, but much more difficult to do overall)
Not sure if this'll actually work or not, but:
-(void)[QCPatchController setPatch:(QCPatch*)thePatch];can be used to set the patch.
-(QCPatch*)[QCRenderer patch];can be used to get a QCRenderer's patch (the root macro patch).
So, given a QCRenderer
qcrand a QCPatchControllerqcp, you might be able to set the patch with the following:[qcp setPatch:[qcr patch]];thanks for the tip ;)