Forgot to copy this to the list earlier, sorry. The second part has
been covered since, hope the first part may still prove useful.
Hi Milton
I haven't tested your reported dealloc bug, but remember that the QC
editor is probably not going to be the app in which your plugin is run
by end-users. If it's causing a problem for you at testing, then set
Xcode to launch another QC-cabable app when you hit run.
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!
I don't see the catch 22 here.
You need to sit down and design a couple of classes to dispense
devices so they can be acquired and shared across plugins. You could
subclass QCPlugInViewController to retain and release the device as
long as the view is around. You could also acquire and retain them in
startProcessing: and release them in stopProcessing:, or at plugin
init/dealloc, whatever performs best in the way you anticipate your
plugin being used. It should be simple to share the same device (and
textures/buffers) across multiple plugin instances, and dispose of
devices when no plugin retains them.
If you don't want to, there's no need to access the device in
createViewController. You could have a button in the view which
accesses the device and exposes the options when clicked.
createViewController does get called a lot in the QC editor, so this
might improve performance there.
I looked at inputs and but the first major stumbling block was I
could never figure out how to limit the values into a rational range
so that the user gets what they want. In most cases hardware wants
discrete value ranges so that the is actually changing something
with their supplied value. So if a controls supports a range of 0
to 23, there is zero sense having it as a float of -1.0 to 1.0 I
seem to recall someone complaining about this from lurking on the
list for almost a year to see what problems developers people had
with it before I dipped in my toes.
Also inputs don't handle things like dynamic change. For example I
am using Device A and want to switch to using Device B or C or E
from within the same plugin. There is no way to handle that with an
input, because the end user would never know if and input value of
0.23 is device "B" or if it's Device "E".
You can set minimum and maximum values for inputs, add and remove them
at run-time, and supply strings to populate pop-up menus, and name
inputs. I'm not as hardcore as vade about everything being exposed as
inputs, but if you want to go that route it is easy to do. Type
QCPortAttribute into the search field of Xcode's documentation window,
and also see addInputPortWithType:forKey:withAttributes:. A glance at
the Quartz Composer Custom Patch programming guide might help too. As
you say, inputs are read-only, so you would either have to rethink
ways of describing parameters so you have none that affect another's
value, or abandon inputs for configuration and have them in your
settings view.
The job you've taken on isn't trivial, but don't let that put you off.
Tom
On 23 Oct 2009, at 17:21, Milton Aupperle wrote:
On 22-Oct-09, at 6:13 PM, vade 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?
I looked at inputs and but the first major stumbling block was I
could never figure out how to limit the values into a rational range
so that the user gets what they want. In most cases hardware wants
discrete value ranges so that the is actually changing something
with their supplied value. So if a controls supports a range of 0
to 23, there is zero sense having it as a float of -1.0 to 1.0 I
seem to recall someone complaining about this from lurking on the
list for almost a year to see what problems developers people had
with it before I dipped in my toes.
Also inputs don't handle things like dynamic change. For example I
am using Device A and want to switch to using Device B or C or E
from within the same plugin. There is no way to handle that with an
input, because the end user would never know if and input value of
0.23 is device "B" or if it's Device "E".
The current GUI way uses menu options that need to be verbally
designated or check boxes or radio buttons that make no sense to try
and implement with an input. Also some parameters are interactive
and changing one parameter changes others simply because that's how
the devices operates.
For example, if the user switches from NTSC to PAL Video, the Video
width, height and frame rate changes too, so that would need to fed
back to the input so they know it changed. But there's no way to do
it because input is one way. If they switch from single field to
interlaced to double field, that changes the height parameters. And
there is also the time it takes to tear down and re-initialize the
isoch channels when the user does something that will cause it to
need to be re-built, like changing format, video size etc. either.
That would be a very stupid thing to expose as an input and would
have a huge impact on Mac performance.
The last thing your missing is how does a user know what each input
does and what are expected parameters. They have to read a document
and lets face it, people don't read anything anymore. That's why a
GUI interface makes so much sense, it's all laid out in front of
them, they can adjust it at will and it has Tool Tip / Balloon Help
to give them more information. How many users are going to figure
out how to increase/decrease brightness when all you have is an
input on the side of the plugin?
So inputs could be implemented for some things, but overall they
make very little sense for the bulk off it and a GUI is necessary.
And the current architectures makes doing a GUI impossible if -
dealloc isn't ever called for the QCPlugin because of the catch 22.
Milton J. Aupperle
President
ASC - Aupperle Services and Contracting
Mac Software (Drivers, Components and Application) Specialist
#1106 - 428 Chaparral Ravine View SE.
Calgary Alberta T2X 0N2
1-(403)-453-1624
[email protected]
www.outcastsoft.com
_______________________________________________
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/bangnoise%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]
