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/archive%40mail-archive.com
This email sent to [email protected]
