Changing the email subject as to not thread hijack (sorry about that)
Indeed, there are totally times when the custom view apparatus is
necessary, and that some combinations of settings may be mutually
exclusive, so having the custom view makes total sense. I just try to
avoid it as much as possible to keep things as inter-operable as
possible. My point to Milton was that his possible catch-22 could be
avoided by forgo-ing the Settings view completely and providing input
ports for the settings he exposed there, should that be a reasonable
approach and not cause confusion or a loss of functionality.
Additionally, for preview output, just supply a secondary
QCPluginOutputImageProvider output port. This would let app developers
provide custom preview controls using his plugin for the DFG or what
not device.
Personally, the reason I use Quartz now and not other tools like Max/
MSP/Jitter is mostly for the Quartz Composer Application interface.
Its amazingly powerful. The settings UI is one of those weird things
that sits on the sideline and can make some options odd.
One work around I've used for things like that antialias option on the
Sprite, or the Billboard 'Native Core Image Rendering" checkbox is to
simply use a De-multiplexor patch upstream and create two Billboards,
one with the option enabled, one without. That works to some extent,
but that approach can be unusable for patches with many options.
On Oct 22, 2009, at 9:25 PM, Keith Lang wrote:
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]
