Re: GarageBand moves my AUCarbonView's pane, sneaky style
Re: GarageBand moves my AUCarbonView's pane, sneaky style
- Subject: Re: GarageBand moves my AUCarbonView's pane, sneaky style
- From: David Duncan <email@hidden>
- Date: Wed, 24 Mar 2004 20:19:15 -0500
On Mar 25, 2004, at 07:15 AM, Art Gillespie wrote:
And while we're discussing GB's window. Did anybody ever anticipate
that hosts would give us kUtilityWindowClass windows for our views?
This is likely because Cooca uses the Window Server's window levels,
but Carbon does not. Therefore you would need to use the
kUtilityWindowClass class to get a window that floats above cocoa
windows. Fortunately they act like standard floaters (i.e. hide when
GarageBand is not frontmost).
But when I look at the AudioUnitCarbonViewCreate documentation, I
don't see any restriction or guidance on the class of window that may
be passed in.
Exactly, because you should not and cannot assume one.
Does this mean that plug-in developers should be prepared to draw into
any class of window?
Absolutely!
Can we really be expected to deliver optimal, Mac-like user
experiences when we can't even guarantee that our window won't be
application modal? (Absurd example to illustrate a point. Surely no
host would ever do this. But then again, I wouldn't have thought that
any host would use Utility Windows, either)
Why wouldn't you expect an application to use a Sheet window for a GUI
plugin? It seems perfectly logical to me that a simple host might put
your GUI in a sheet window. While using a help tag window might be an
interesting exercise I don't think it would happen. However think that
it is also possible to put your GUI inside a Menu on Panther :).
We have such beautiful and well-defined interfaces for audio data and
parameters, but certain aspects of the view just seem to be 'anything
goes' affairs -- your view could be compositing, could be
non-compositing, could be a document window, could be a utility
window. I'm content to work around this stuff to reach our customers,
and I don't want to sound like I'm complaining, but doesn't it seem
like all interested parties could benefit from a better-defined view
interface?
Personally I would like to see non-composited windows dropped
completely - I simply do not see the point. Aside from that you really
shouldn't need to be concerned with how your GUI is displayed, as each
host will almost certainly make choices that the developer feels is
important to their application and will make the decisions only to the
extent that their test base shows no issues.
--
Reality is what, when you stop believing in it, doesn't go away.
Failure is not an option. It is a privilege reserved for those who try.
David Duncan
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.