Thanks Vade, that helps muchly. Let’s take a simple example, Sprite, which has one Checkbox in it’s Settings inspector—antialiased edges. What would be the reasons for making this un-noodle-able? Is it because this depends on Blending being set to Over or Add? Or might there be some other (engine-related) reason why it’s not available simply as an input?
I can understand why this is more complex for patches like Timeline, which require richer input, that breaks with the current ability to set input values on input ports (even if no noodle is attached the the input port.) Keith On Fri, Oct 23, 2009 at 11:51 AM, vade <[email protected]> wrote: > Lets say you write a plugin that has a special patch, call it uh, v002 Foo > for arguments sake :) > > v002 Foo has some input and output parameters, these are the standard "I can > connect them to other things via noodles/patch-coords" in QC input and > output ports. However, if I decide to make the plugin have a Settings > inspector view, ( a custom view like the interpolation patch - you can see > this by going to settings / Apple-2 when you have the patch inspector open > when viewing the interpolation patch, the special ), controls I make in > there are limited to being touched/fiddled with in Quartz Composer Editor > only. > > Since controls in the Settings pane have no external input or output > publishable ports, this means you cannot: > > a) programatically set them from within Quartz Composer > b) publish them so that an external, Quartz Composer friendly application > can use a custom UI to make controls and actually send values to those > params in the view > c) limits settings in that view from being changed outside of Quartz. > > This is why I don't personally make plugins that do that (have custom > setting user interfaces), and have all controls publishable as inputs ports > so you can use them from 3rd party apps and programatically edit them. This > makes them end user friendly so you can control them from QC, and lets the > composition or plugin be used in apps that leverage QC much more easily. > > Now, my proposed solution to being able to 'get at' these Settings panes > that are locked to only being available in Quartz Composer Editor (as far as > I know you cant get at them any other way), is to extend the > QCRenderer/QCPlugin API to allow applications to get an NSView object from > the Plugin and draw it in their host app. This alleviates all of the listed > limitations from above, so I as an app developer can let you get at and > manipulate the custom look up curve in the interpolation patch within my > nice, shiny, beautiful Cocoa App and not just have it hidden away in QC. > > So, as far as I am aware, there is no public way of getting at those plugin > custom controls from a Cocoa App, and since so much of what is lovely about > Quartz Composer is the app integration, thats a real shame. > > Maybe thats a bit more clear where I am coming from? > > On Oct 22, 2009, at 8:32 PM, Keith Lang wrote: > >> Vade >> >> Would you be so kind as to extrapolate on what you said… for the >> lurking non-programmers like me please? >> >>> Being able to get an NSView object from a plugin and being able to >>> drop it into a nice designed UI would be really cool, especially for >>> patches >>> like interpolate and timeline with interesting parameters.). >> >> >> Are you saying it your suggestion is to allow 3rd party QC interfaces >> to replace/augment the current inspector interfaces in patches like >> Timeline? That is, to have the very interface elements of the QC >> Editor be QC’s themselves? >> >> Keith >> >> >> >> >> On Fri, Oct 23, 2009 at 11:13 AM, vade <[email protected]> wrote: >>> >>> Just as a developer and an end user, I really frown upon using view >>> controllers for custom QC patches. The reason is simple as this: >>> >>> you cannot publish controls exposed in the view controller to the host >>> app >>> since they have no outlets or inlets, nor can you publish the view itself >>> to >>> the host app* >>> In short, if your patch has controls, please make them standard input >>> ports, >>> so they can be used with 3rd party Quartz friendly apps by other devs. >>> >>> Just saying :). Why not make your controls parameters? >>> >>> *(this is actually a pending feature request of mine, and i think would >>> be >>> awesome. Being able to get an NSView object from a plugin and being able >>> to >>> drop it into a nice designed UI would be really cool, especially for >>> patches >>> like interpolate and timeline with interesting parameters.). >>> >>> On Oct 22, 2009, at 5:31 PM, Milton Aupperle wrote: >>> >>>> So we have a catch 22 situation here. The device doesn't get accessed >>>> from >>>> the -createViewController until the -startExecution method gets called >>>> because it hasn't been opened yet and -createViewController is already >>>> allocated by the plugin so it's all set to fail!. And if device is >>>> released >>>> in the -stopExecution call, then it once again can not be accessed at >>>> all in >>>> -createViewController. This is just a very poor user experience - I >>>> expect >>>> Apple to be better than this kludge! >>>> >>> >>> _______________________________________________ >>> 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/songcarver%40gmail.com >>> >>> This email sent to [email protected] >>> > > _______________________________________________ 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]
