Hello
I may be misunderstanding something with how bundle loading in general
works, or perhaps stumbled on a bug in QC, or not understand something
subtle about the Obj-C runtime.
In optimizing how my plugins work, i created some stand-alone and re-
usable classes to remove duplicate code. Things like consolidating GL
code into FBO objects, Shader objects and a master QC plugin that
some of my plugins inherit from. These classes are v002FBO,
v002Shader, v002MasterPlugininterface.
I now have a few plugins that leverage these classes, meaning that
various qc plugin bundles may have differing versions of 'v002FBO' etc
used within its compiled /executable code, due to their 'in
development status. Note none of those classes are advertised in the
info.plist as QCpluginClasses, they are just used internally by the
plugin.
In troubleshooting a problem I was having with some a plugin, I
realized that if a qcplugin bundle is loaded by QC that uses an older
version of one of those classes, none of the other plugins use their
own compiled in versions of these classes. In other words, one plugin
can overwrite another's internal classes due to just having the same
name.
To be clear:
Plugin A uses an older copy of v002FBO, which is compiled and added to
the Quartz Composer Plug-Ins directory.
I create a new plugin (Plugin B), add those above classes to it, and
decide to add some log statements to my v002FBO class to troubleshoot
something. I compile and place the plugin into the standard QC Plugins
directory.
Now Plugin A and B both have references to v002FBO, but one has
logging, the other does not.
Loading QC, making a new composition and instantiating Plugin B shows
me logging does not work. Quitting Quartz Composer, manually removing
Plugin A, relaunching, now logging from Plugin B works.
This means plugins can effect one another's ability to function? Am I
misunderstanding something about bundles? Is this a legitimate bug?
How should one go-about adding re-usable classes to bundles to provide
functionality, but keep those classes private (assuming we want our
plug-ins to be able to subclass and still reference ivars from the
superclass - using @private would kill this funcionality, no?). Would
having a framework be a solution? Im still concerned however because I
can see some scenarios happening where end users could download a
newer plugin that has some changes to a base class that could pollute
older plugins and break them.
Thanks, Im expecting to be misunderstanding something subtle in Obj-C/
Bundles, but realizing that a Plugin A was polluting the functionality
of Plugin B has me a bit concerned.
Thanks, looking forward to any pointers.,
_______________________________________________
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]
