Re: linked Cocoa-Carbon windows for AUCarbonViews
Re: linked Cocoa-Carbon windows for AUCarbonViews
- Subject: Re: linked Cocoa-Carbon windows for AUCarbonViews
- From: Marc Poirier <email@hidden>
- Date: Tue, 27 Sep 2005 11:11:21 -0400
Yes, I very much like that idea! Much more than my idea... :)
Marc
On Sep 27, 2005, at 10:56 AM, Stefan Gretscher wrote:
Hi Marc,
this is something I've been considering as well recently.
I don't think that an AU should access anything outside the view
it's been assigned to, it certainly should not touch any grouped
windows.
How about instead changing the hosts apps so that they set those
areas of their grouped windows to full transparency which are
placed underneath the actual AU UI?
For non-transparent AU UIs, this makes no difference at all because
the AU completely hides the area in question, and for transparent
AU UIs it would work as expected.
What do you think?
Stefan
Am 26.09.2005 um 22:09 schrieb Marc Poirier:
Hello. You know how some AU hosts (Logic, GarageBand, AU Lab,
etc.) do that trick of placing a Carbon "overlay" window for an
AUCarbonView over a Cocoa window, and link the windows together in
a window group, so that they can have it be like a Cocoa window,
but still show the AUCarbonView? That's what I'm writing about
today...
I was just wondering if there is a way for the AU to
programmatically determine when this situation is the case, and
get access to all of these linked windows. I was thinking of
maybe calling GetWindowGroupOwner()? Or possibly just iterating
through the result of CountWindowGroupContents() with
GetIndexedWindow()? But I'm not sure if either of those ideas
would be reliable:
1) in the case that relatively unrelated, non-linked windows may
be in the same window group,
2) if the base window may not be the owner of the group, or
3) if there may not even be such a window group, that being a
Carbon thing which maybe doesn't jive with Cocoa windows.
So I was wondering if this approach may work or maybe not at all,
and if not, if there might be any approach that I could take?
thanks,
Marc
p.s. - So the reason why I want to do this is because I've added a
feature to my DFX GUI library which allows the user to adjust the
transparency of the AU editor window. The results in these
"linked windows" are rather unsatisfactory, though, since all you
wind up doing is making the overlay window translucent, revealing
nothing more than a blank Cocoa window behind it. And I realize
that folks are thinking, "Well, you shouldn't be doing that to a
window as an AU. The host owns the window, not the AU." Yes, I
know, but I still want to do it anyway. :) I just think that
it's such a nice feature. When you have a ton of plugins open and
they are totally covering your song arrangement, it can be very
handy to be able to sort of see the arrangement behind the plugin
GUIs. And so far as AU hostile take-overs of the host go, I think
that this one is really benign. I mean, the worst case is that
either the host overrides this with its own window transparency
setting (which would be fine), or that the user says, "wait I
don't like that," in which case all you do is go back and turn the
transparency down to none. It's not a destructive change at all.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden