On 2008-04-28 20:20:25 +0200, "Yan Shapochnik" <[EMAIL PROTECTED]> said:
Hello Trenton,
Thank you for your response. By your explanation, it seems that this would
be an issue with any 3rd party application and not just with a java
application. This is what the NSApplicationAWT interface looks like:
@interface NSApplicationAWT : NSApplication
{
NSString *fApplicationName;
BOOL bUseDefaultIcon;
}
...
...
@end
with a number of methods defined before the @end. This interface definition
resembles common interfaces in other Cocoa applications as suggested by
Apple.
If I wanted to create a plug-in written using the Qt Cocoa API and want that
plug-in to be loaded by some 3rd party Cocoa application on Mac OS X
conforming to Apple standards, I would run into similar issues, since their
implementation would most definitely not have methods named setQtPrivate.
Qt makes a call to NSApplication's class level method sharedApplication to
create an NSApplication instance if one does not exist:
[NSApplication sharedApplication]
However, if one does exist, it just returns the existing instance. Qt should
handle this gracefully in my opinion. Some rearchitecting will be required
and perhaps Qt Cocoa exposes some type of QApplicationPlugin class which
handles this properly for plug-ins. This class could call [NSApplication
sharedApplication] but if this method does not return an instance of a
QCocoaApplication then it would add observers to receive notifications and
handle them appropriately if they are meant to be handled (meaning, the
events have to do with Qt objects).
I briefly looked into delegates, but it looks like an NSApplication instance
could only have 1 delegate and Qt would not want to override a delegate set
by AWT or some other application if that is in fact the case.
Do you think implementing something like this is possible?
What you said was essentially correct. We can work around the qtPrivate
issue by making it a category. The problem is that NSApplication (and
Cocoa in general) has the idea of one delegate and no "bubbling" up of
events. It's one place where Carbon events really, really shines. It is
possible to work around this, but only in an informal way that others
have to agree to (basically publish our QCocoaApplication). The problem
is that, unless the developers control the application (a.k.a.
application developers and not plugin developers), they might not have
the abliity to even agree. I'm still not a Objective-C guru, so if
there for some reason is someone here that has an idea I'll certainly
listen.
The only other way I can think about it is that we essentially say,
"these things won't work if Qt can't control NSApplication." What that
list is, I can't say at the moment.
The best I can tell you at the moment is that we are aware of this and
that people do use Qt in plugins on Mac OS X and that they should be
able to do that in Cocoa. What is the current implementation to will
achieve that? I don't know at the moment, but we want to solve it.
Probably not the best answer ever, but hopefully it helps answer your question,
-- Trenton
To unsubscribe - send "unsubscribe" in the subject to [EMAIL PROTECTED]
