Re: Cocoa views for AU
Re: Cocoa views for AU
- Subject: Re: Cocoa views for AU
- From: Airy André <email@hidden>
- Date: Thu, 21 Aug 2003 15:59:24 +0200
You can find the protocol as defined by Bill Stewart in this list in
March.
As far as I know, no change has been made public since then.
Please note I have no AU ready for this yet.
But if there some developers interest for it (and host writers too, of
course - but the two are quite linked), I may go for a Cocoa version of
AUGUIFramework, with a bunch of NSView classes and IB palettes to use
for AU Cocoa GUI development.
I am quite sure a lot of developers here would like to use Cocoa for
their UI development.
Airy
Here is a copy of the Bill proposal :
-----
From: Bill Stewart <email@hidden>
Subject: AudioUnits and Cocoa UI
Date: lundi 17 mars 2003 18:03:48 Europe/Paris
To: email@hidden
OK...
Here we go.
This is a proposal that I want to pass by this list before we set this
in stone that would enable an AudioUnit to communicate to a host that
it has a UI that has been written for it in Cocoa.
We looked at trying to provide a bridge that would present the same API
for both Carbon and Cocoa hosts, but this seems untenable at this time
(primarily because in a Carbon app, any Cocoa code has to run in its
own window and that window *cannot* be drawn in or interacted with as
if it were a Carbon window)... As many host apps like to have toolbars
on their plugin windows, to do so with a Cocoa view would require Cocoa
code anyway.... The good news though, is that it is not that difficult
for a Carbon app to have a cocoa window within it, there is an example
of this in the Carbon SDK (CocoaInCarbon), so if Carbon hosts *want* to
do this (and we aren't requiring this either - just to be clear), they
can...
So once in place this will leave us with the following relations:
Carbon View - Carbon App
Carbon View - Cocoa App - needs to be in a separate "Carbon" window,
but can have other Cocoa code around it
Cocoa View - Carbon App - can be embedded in a "Cocoa" window - only
has Cocoa code (ie. no Carbon drawing, controls)
Cocoa View - Cocoa App
I should also make it clear that the most easily and broadly supported
UI is still Carbon, so if any AU developer is concerned at this point
about broad usability, a Carbon View is certainly more broadly
supported. However, we also understand the attractiveness of Cocoa for
UI development and see a great potential for the sharing of UI objects
and widgets that can make this both an interesting and worthwhile
endeavour (how do you spell that!).
OK - the details:
Each audio unit that supports a cocoa UI view must support the
following property: kAudioUnitProperty_CocoaUI
The value of this property is the following struct:
typedef struct AudioUnitCocoaViewInfo {
CFURLRef mCocoaAUViewBundleLocation;
CFStringRef mCocoaAUViewClass[1];
};
mCocoaAUViewBundleLocation - contains the location of the bundle which
the host app can then use to locate the bundle
mCocoaAUViewClass - contains the names of the classes that implements
the required protocol for an AUView
The AU can return an array of these view info structures (similar to
the CarbonUI view component id's), and the host can easily determine
how many of these are present through the size of the property itself.
We will also define a protocol that we expect Cocoa AU Views to
implement:
#import <Cocoa/Cocoa.h>
@protocol AUCocoaUIBase
// Returns version of the interface youre implementing
// You should return 0 for now.
- (unsigned) interfaceVersion;
// Returns NSView responsible for displaying the interface
- (NSView *) uiViewWithSize : (NSSize) inPreferredSize;
// Returns an array of AudioUnitParameters bound to the
// view or control at the specified location in the uiView
- (NSArray *) paramListForControlAtLocationInView:
(NSPoint) pt;
@end
The paramListForControlAtLocationInView defines a method that a host
can use (similar to the Carbon Views) to control the over-dubbing of
parameter values. The Carbon approach provides a callback to notify
hosts of user interactions. However, this approach is not convenient
for cocoa developers because it would potentially require the plugin
view to override NSResponders mouseDown: method for every control in
the view in order to invoke a similar callback. This can be especially
cumbersome if InterfaceBuilder is used to make the nib file. Instead,
it is suggested that the host trap mouseDown events in the plugin view
by overriding sendEvent: in either a subclass of NSApplication or
NSWindow. When the host is recording automation, it would trap
NSLeftMouseDown events. If the event occurs in the coordinate space of
the plugin view, the host can call paramListForControlAtLocationInView:
with the location of the event (in view-relative coordinate space) to
determine the parameter (or parameters) that it needs to record until
the next NSLeftMouseUp.
The AU Views would be responsible for implementing the
paramListForControlAtLocationInView: method specified in the
CocoaAUView protocol. This method should determine which subview or
control is at the specified point and then return an NSArray of
AudioUnitParameters for the matching control.
Packaging
It is recommended that each UI bundle reside in the component package
of the audio unit that owns it. The bundle should reside in a Plug-ins
directory at the top level of the component. The bundle should have a
.bundle extension.
Localization
Bundles should be designed with localization in mind. All strings and
other resources to be localized should be stored in the appropriate
location: Contents/Resources/English.lproj (for example).
Host Application Responsibilities
Cocoa Host apps would get the Audio Unit component and then query the
kAudioUnitProperty_CocoaUI property to see if the audio unit has a
cocoa ui.
The following method in NSBundle can be used to get a class for the
string:
- (Class) classNamed: (NSString *) className
The class can then be instantiated using [Class alloc] init;.
Once the class is instantiated, the host can get the ui view by calling
uiView which returns an NSView. It is the responsibility of the host to
check the size of the returned NSView and install it in a scroll pane
if it is too big to fit in the desired location.
Comments are welcome.
Whilst we will eventually publish this protocol and propertyID in our
headers, this does not need any specific support from us, so if there
is a general agreement we can go ahead with this. At that time, I'll
give out the property ID number and away we go...
Bill
On jeudi 21 ao{t 2003, at 15:25, Patrick Gostovic wrote:
I am writing a host in cocoa, but I was not aware of any standard
mechanism for obtaining a handle on a cocoa view from an AU. If there
is a way, please enlighten me and I will support it.
pg
On Thursday, August 21, 2003, at 07:19 AM, Airy Andri wrote:
Is there any host writer working at supporting Cocoa views for AU ?
Airy
_______________________________________________
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.
_______________________________________________
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.