Re: linked Cocoa-Carbon windows for AUCarbonViews
Re: linked Cocoa-Carbon windows for AUCarbonViews
- Subject: Re: linked Cocoa-Carbon windows for AUCarbonViews
- From: Stefan Gretscher <email@hidden>
- Date: Tue, 27 Sep 2005 16:56:04 +0200
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:
email@hidden
This email sent to email@hidden
_______________________________________________
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