http://www.cocoabuilder.com/archive/message/cocoa/2008/2/17/199174Has some info too. I see now where the problem lies. It sounds like a framework is the proper approach, or is doing some OBJ-C runtime hackery required to "uniquify" class names/descriptions during runtime?
[note this is almost entirely QC-unrelated at this point]In general, don't do Obj-C runtime hackery -- it's dangerous, and 99% of the time you can do what you want without resorting to it. If you find a situation where it's /necessary/, you're probably doing something dirty (we only use it to modify existing QC class methods, for example, since categories won't accomplish what some of our mods perform).
Let's say you have 2 plugins , vade001.plugin, and vade002.plugin. They both use vade003.framework, which defines the VadesRadClass object.
QC will load either vade001.plugin or vade002.plugin first (doesn't matter which, and you should never depend on the order anyway) -- at plugin load time, the linker (dyld) will notice that your plugs link to the vade003.framework, so it will get loaded too (creating VadesRadClass).
Then, QC will load the other plugin (whichever didn't load above), note the same framework, and say "oh, I've already got it loaded, cool", and nothing additional is required. Both will use the same class, and everyone's happy.
The problem with this setup (yes, I've thought about this a _lot_ because we've run into similar situations -- our ad hoc solution has been to just bundle plugins together that use similar functionality) is that the location of vade003.framework isn't well-defined. Depending on design, this could be unimportant, or Really Really Important. It could be in each plugin's internal framework folder (bundle/Contents/Frameworks or something), in which case only _one_ will get loaded, and you have no control over which one. If they're identical, it's largely a who-cares situation (you just waste diskspace), but if they're different, you're back where you started -- loading 2 frameworks that define the same class name will collide and do bad things in arbitrary order. The name collision stuff is what you're experiencing now, and there isn't a way around it at all. Even runtime hackery can't magically fix it (unless both classes have next to zero overlap ivar-wise, and zero overlap method-name-wise as well).
You could alternatively put the framework somewhere system-wide, like / Library/Frameworks or ~/Library/Frameworks. This is standard, but end- users tend to not like that much. We tried it for early alphas of kineme3d, and it ended up causing more problems than it solved, but your situation might be different.
I'm thinking you're better off just packing them all into a single big plugin -- less linker junk to deal with, fewer wasted partial code pages, and no need for frameworks/tricks. That's just me though.
-- [ christopher wright ] [email protected] http://kineme.net/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
