Installing the Skanky SDK on 10.7

I'm not sure about installing on 10.7... if you "had" the Dev folder, I know it works. Maybe it's possible for you to setup the folder structure, or DL the Xcode/Dev Tools from before that stuff went away. BTW, the SkankySDK is pretty much setup for plugin development - I've run into some stuff that shows some flaws for app development (it doesn't replicate all of the methods, so I wind up just rolling my own private API). That said, it doesn't take the skankySDK to load the patches...

I usually sort my QCPlugins and QCPatches into two different folders, so that it's easy for the QCPlugin method to not try to load QCPatches (which will result in some console messages, and maybe whacky stuff).

I make a "Quartz Composer Patches" folder inside of the built in Plugins path, and add it in the "Copy Files" under Target, and all of the skanky/GFPlugins are in there. Then the code for QCPatch loading would go like this, in the ".m" implementation file:

//Load QCPatches "skanky"/private api from main bundle "Quartz Composer Patches" path
   NSString    *qcpatchPathInternal = [ [mainBundle builtInPlugInsPath] stringByAppendingPathComponent:@"Quartz Composer Patches"];
 
   [QCPatch loadPlugInsInFolder:qcpatchPathInternal];

Loading QCPlugins is a little different, because there's no method to just "load them all" like there is with QCPatch. Since let them hang out in the main resource bundle's built in plugins path, and don't usually bundle them into there own "specific" resource folder the way I will QCPatches. That will look like this:

NSBundle *mainBundle = [NSBundle mainBundle];
   //internal qcplugin path will be inside of the built in PlugIn folder option. QCPatches will be in a folder inside of this folder.
   NSArray    *qcpluginPathsInternal = [NSBundle pathsForResourcesOfType:@"plugin" inDirectory:[ [NSBundle mainBundle] builtInPlugInsPath]];
 
   for (NSString *path in qcpluginPathsInternal)
    {
        [QCPlugIn  loadPlugInAtPath:path];
    }

I'm attaching a pic so you can see the kind of folder structure I'm talking about, and what I mean by "built in Plugins path" (if you don't get that still, do some searches on resource and plugin loading from bundles.)

Preview	Attachment	Size
	plugin loading folder struct.jpg	135.52 KB

don't bother with the install script just add the skanky headers to your project. i use a structure similar to george's as well by utilizing the plugins folder. normally Xcode wants you to add your plugins source project file to your app project file. that way when you do a copy to plugins folder in your build phases your plugin target will be selectable via the drop down list. this however isn't always possible (having the source project for a plugin).

in this case i drag and drop the raw plugins to a app project and then remove them from the copy to bundle resources build phase. (no need for multiple copies of your plugin). then create a new copy file build phase and make sure to select a destination of plugins, then drag and drop the official plugin into that build phase. secondly create another copy file build phase with destination set to plugins but this time make a subpath like "skanky" or "patches" then drag n drop the un-officials to that build phase.

now your plugin's are ready to load like above. make sure to remove the plugins your using from your /library/graphics folder as qc will load them first which defeats the purpose of loading a plugin from a different location....

something also important to note is that you will want to load your plugins before you load your composition. see attached example project....

//
//  main.m
//  patchLoader
//
//  Created by Dustin O'Connor on 7/19/12.
//  Copyright (c) 2012 d0cut0uch. All rights reserved.
//
 
#import <Cocoa/Cocoa.h>
#import "SkankySDK.h"
 
//official plugin interface
 
@interface QCPlugin
-(void)loadPlugInAtPath:(NSString*)path;
@end
 
 
int main(int argc, char *argv[])
{
 
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
 
    //load official plugin
    NSString *plugFolder= [[[NSBundle mainBundle] builtInPlugInsPath] stringByAppendingPathComponent:@"Syphon.plugin"];
 
    if (![QCPlugIn  loadPlugInAtPath:plugFolder])
    {NSLog(@"could not load official plugin [%@]", plugFolder);}
 
     //load skanky patch
    NSString    *patchFolder = [[[NSBundle mainBundle] builtInPlugInsPath] stringByAppendingPathComponent:@"patches"];
    [QCPatch  loadPlugInsInFolder:patchFolder];
 
    int retain = NSApplicationMain(argc,  (const char **) argv);
   [pool drain];
   return retain;   
 
}

I believe you do not need to be setting up the NSAutoreleasePool, the main function here will be setting up an application wide pool.

Also, if you load them from the same folder like that, I believe that either the QCPlugin or QCPatch method tried to load the other, and complains about it. This is why I set it up the way I do... I might possibly create a separate "Quartz Composer Plug-Ins" folder, inside of the built in PlugIns folder, I guess.

To load QCPatch, all you need to do is #import "QCPatch.h" in the header.

Hey, your milage may vary, but I have done it the way you're doing it and changed it to what I posted above for these reasons.

yes you may run into problems with the autorelease pool if your building with arc turned on in 10.7. the official plugin loading in my example works for a single plugin and shouldn't effect the bulk patch loading as the patches are in there own folder. like george mentioned if you are wanting to bulk load your official plugins then making a sub folder and calling a loop like george posted is the ideal way to load them all in one shot.

No, I'm not talking about if ARC is on. I'm saying that doesn't need to be done there. The application sets up a pool for that automatically, in 10.5 or 10.6, or 10.7, it's just how it works. No biggie. I think you might want to do that if you were loading in the prefix, but I'm uncertain about that.

Also, methods that return arrays of plugins (like the load qc patches, or the one I use to return all of the qcplugins) have an implicit autorelease... so it can get "wrong" if you start doing that there. I didn't know this and it was pointed out to me by Steve Mokris when I asked him to vet some plugin loading code. You don't need to setup an autorelease pool there or do anything like that, assuming the loading is going on in the main implementation.

Didn't read correctly the way that you had the folders setup separately, I guess my eyes went whacky :)

without creating an autorelease pool and draining the pool i get memory leak warnings like this....

objc[11748]: Object 0x102c22b90 of class GFNodeClassDescription autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug
objc[11748]: Object 0x102c22f10 of class GFNodeClassDescription autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug

it seems others on the dev list have suggested loading in the main implementation so that has been where i have been loading them from... this has not caused any problems for me yet but in all fairness of correctness you certainly can load your plugins from lets say your document's init method. i don't think the directory (plugins folder) or (frameworks folder) etc... and where you load the plugin from in your code really matters as long as you load them before you load the composition that needs them.

#import "Document.h"
#import "SkankySDK.h"
 
@implementation Document
 
- (id)init
{
    self = [super init];
    if (self) {
        //load official plugin
        NSString *plugFolder= [[[NSBundle mainBundle] builtInPlugInsPath] stringByAppendingPathComponent:@"Syphon.plugin"];
 
        if (![QCPlugIn  loadPlugInAtPath:plugFolder])
        {NSLog(@"could not load official plugin [%@]", plugFolder);}
 
        //load skanky patch
        NSString    *patchFolder = [[[NSBundle mainBundle] builtInPlugInsPath] stringByAppendingPathComponent:@"patches"];
        [QCPatch  loadPlugInsInFolder:patchFolder];
 
    }
    return self;
}

You bring up the greater point that you should always test code.

In the case of what I'm talking about, it was actually the right thing to do, and cleared up a leak. I'm not sure what code you did test, so it's hard to say. Maybe there's some aspect of where it is being called or some other line of code going awry? I certainly don't doubt you're seeing what you're seeing, just relating my experience.

The main() function calls NSApplicationMain(), and sets up an application-wide pool that gets drained every cycle of the event loop.

This is the reference on it, which is really a generally good thing to read up on (not suggesting this to you Dust, just any readers). https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/F...

On another note, if anyone is trying to use private methods for app development and finds the compiler whining about problems with the skankySDK -

I've had more success using class dump to generate headers to include, and use as needed. That's at least one way of dealing with it. There are a few public methods and other things that either aren't in the skankySDK or are in conflict... usually when dealing with stuff revolving around public port types or QCPlugin, and a few other public methods. (I'm not wantonly saying this, it's been gone over w/ the folks @ kineme.)

Thank you guys, much appreciated, i'll be looking though all this today. Thank you