Qt4-preview-feedback Archive, April 2008
Qt 4.4.0 Mac OS X Cocoa alpha (JNI feedback)
Message 1 in thread
I am experiencing an issue with a simple JNI app on Mac OS X using the 4.4.0
Cocoa Port alpha and Mac OS X 10.5.2 w/ Apple's JVM 1.5.0_13-b05-237.
The java application is a very simple Swing application. It displays a frame
with a button. Once the Swing button is clicked it makes a call via JNI to
the native library which uses Qt to attempt and display a QMessageBox
modally.
Here is a code snippet from the native implementation:
#include <QtCore>
#include <QtGui>
#include "HelloWorldImp.h"
JNIEXPORT void JNICALL Java_HelloWorld_displayHelloWorld(JNIEnv *env,
jobject obj)
{
int argc = 0;
char *argv[] = {""};
QApplication *pqapp = new QApplication(argc, argv);
QMessageBox mb;
mb.exec();
}
When I click the Swing button and a call is made into native library, the
application crashes with the following error:
2008-04-21 15:15:09.301 java[29340:13a03] *** -[NSApplicationAWT
setQtPrivate:]: unrecognized selector sent to instance 0x125430
2008-04-21 15:15:09.303 java[29340:13a03] An uncaught exception was raised
2008-04-21 15:15:09.303 java[29340:13a03] *** -[NSApplicationAWT
setQtPrivate:]: unrecognized selector sent to instance 0x125430
2008-04-21 15:15:09.304 java[29340:13a03] *** Terminating app due to
uncaught exception 'NSInvalidArgumentException', reason:
'*** -[NSApplicationAWT setQtPrivate:]: unrecognized selector sent to
instance 0x125430'
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 2 in thread
On 2008-04-21 21:41:52 +0200, "Yan Shapochnik" <shapochniky@xxxxxxxxxxx> said:
> I am experiencing an issue with a simple JNI app on Mac OS X using the 4.4.0
> Cocoa Port alpha and Mac OS X 10.5.2 w/ Apple's JVM 1.5.0_13-b05-237.
>
> The java application is a very simple Swing application. It displays a frame
> with a button. Once the Swing button is clicked it makes a call via JNI to
> the native library which uses Qt to attempt and display a QMessageBox
> modally.
>
> Here is a code snippet from the native implementation:
>
> #include <QtCore>
> #include <QtGui>
>
> #include "HelloWorldImp.h"
>
> JNIEXPORT void JNICALL Java_HelloWorld_displayHelloWorld(JNIEnv *env,
> jobject obj)
> {
> int argc = 0;
> char *argv[] = {""};
> QApplication *pqapp = new QApplication(argc, argv);
>
> QMessageBox mb;
> mb.exec();
> }
>
> When I click the Swing button and a call is made into native library, the
> application crashes with the following error:
>
> 2008-04-21 15:15:09.301 java[29340:13a03] *** -[NSApplicationAWT
> setQtPrivate:]: unrecognized selector sent to instance 0x125430
> 2008-04-21 15:15:09.303 java[29340:13a03] An uncaught exception was raised
> 2008-04-21 15:15:09.303 java[29340:13a03] *** -[NSApplicationAWT
> setQtPrivate:]: unrecognized selector sent to instance 0x125430
> 2008-04-21 15:15:09.304 java[29340:13a03] *** Terminating app due to
> uncaught exception 'NSInvalidArgumentException', reason:
> '*** -[NSApplicationAWT setQtPrivate:]: unrecognized selector sent to
> instance 0x125430'
Hi Yan,
I suspect what is happening that Swing implements its own NSApplication
subclass, and so does Qt and there can be only one subclass in an
application. what is happening here is that the Swing subclass is
created before the Qt one, and when we try to use our subclass, it will
through an exception. I would assume you would have other issues if you
created the Qt subclass first and the swing version tried to call its
extra methods.
I've yet to get a good solution to this issue. I'm afraid for the time
being, you simply can't use the Cocoa with a swing Java app. :-(
-- Trenton
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 3 in thread
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?
Thank you and I look forward to your reply.
"Trenton Schulz" <twschulz@xxxxxxxxxxxxx> wrote in message
news:fv4o8k$bra$1@xxxxxxxxxxxxxxxx
> On 2008-04-21 21:41:52 +0200, "Yan Shapochnik" <shapochniky@xxxxxxxxxxx>
> said:
>
>> I am experiencing an issue with a simple JNI app on Mac OS X using the
>> 4.4.0
>> Cocoa Port alpha and Mac OS X 10.5.2 w/ Apple's JVM 1.5.0_13-b05-237.
>>
>> The java application is a very simple Swing application. It displays a
>> frame
>> with a button. Once the Swing button is clicked it makes a call via JNI
>> to
>> the native library which uses Qt to attempt and display a QMessageBox
>> modally.
>>
>> Here is a code snippet from the native implementation:
>>
>> #include <QtCore>
>> #include <QtGui>
>>
>> #include "HelloWorldImp.h"
>>
>> JNIEXPORT void JNICALL Java_HelloWorld_displayHelloWorld(JNIEnv *env,
>> jobject obj)
>> {
>> int argc = 0;
>> char *argv[] = {""};
>> QApplication *pqapp = new QApplication(argc, argv);
>>
>> QMessageBox mb;
>> mb.exec();
>> }
>>
>> When I click the Swing button and a call is made into native library, the
>> application crashes with the following error:
>>
>> 2008-04-21 15:15:09.301 java[29340:13a03] *** -[NSApplicationAWT
>> setQtPrivate:]: unrecognized selector sent to instance 0x125430
>> 2008-04-21 15:15:09.303 java[29340:13a03] An uncaught exception was
>> raised
>> 2008-04-21 15:15:09.303 java[29340:13a03] *** -[NSApplicationAWT
>> setQtPrivate:]: unrecognized selector sent to instance 0x125430
>> 2008-04-21 15:15:09.304 java[29340:13a03] *** Terminating app due to
>> uncaught exception 'NSInvalidArgumentException', reason:
>> '*** -[NSApplicationAWT setQtPrivate:]: unrecognized selector sent to
>> instance 0x125430'
>
>
> Hi Yan,
>
> I suspect what is happening that Swing implements its own NSApplication
> subclass, and so does Qt and there can be only one subclass in an
> application. what is happening here is that the Swing subclass is created
> before the Qt one, and when we try to use our subclass, it will through an
> exception. I would assume you would have other issues if you created the
> Qt subclass first and the swing version tried to call its extra methods.
>
> I've yet to get a good solution to this issue. I'm afraid for the time
> being, you simply can't use the Cocoa with a swing Java app. :-(
>
> -- Trenton
>
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 4 in thread
On 2008-04-28 20:20:25 +0200, "Yan Shapochnik" <shapochniky@xxxxxxxxxxx> 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 qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 5 in thread
On 2008-04-29 09:11:31 +0200, Trenton Schulz <twschulz@xxxxxxxxxxxxx> said:
> On 2008-04-28 20:20:25 +0200, "Yan Shapochnik" <shapochniky@xxxxxxxxxxx> said:
[snip]
>> 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,
I've made some changes to this, so it at least shouldn't be crashing
anymore. It doesn't solve the delegate problem yet. I have some ideas
for it, but I need to thnik about how plausible they are.
I will at least warn about this situation, so it's a better than it was.
You'll have to keep your eye on this when we get around to pushing
another alpha out,
Thanks,
-- Trenton
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 6 in thread
Hello Trenton,
Thanks again for your follow up on this. Just to revisit what I had
previosuly stated.... couldn't this be accomplished using notifications?
If Qt uses the addObserver:selector:name:object: method to register an
observer(s) and receive notifications of all kinds which are typically
designated for NSApplication's delegate?
Notifications trickle down to the observers similar in the way Carbon events
are handled in a Carbon app. I am not familiar with all the details, but
perhaps this could be a potential solution.
What do you think?
Do you have an idea when snapshot builds of Qt Cocoa will be available and
posted by Trolltech?
I look forward to your reply.
- Yan -
"Trenton Schulz" <twschulz@xxxxxxxxxxxxx> wrote in message
news:fv78m3$j05$1@xxxxxxxxxxxxxxxx
> On 2008-04-29 09:11:31 +0200, Trenton Schulz <twschulz@xxxxxxxxxxxxx>
> said:
>
>> On 2008-04-28 20:20:25 +0200, "Yan Shapochnik" <shapochniky@xxxxxxxxxxx>
>> said:
>
> [snip]
>
>>> 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,
>
> I've made some changes to this, so it at least shouldn't be crashing
> anymore. It doesn't solve the delegate problem yet. I have some ideas for
> it, but I need to thnik about how plausible they are.
>
> I will at least warn about this situation, so it's a better than it was.
>
> You'll have to keep your eye on this when we get around to pushing another
> alpha out,
>
> Thanks,
>
> -- Trenton
>
>
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 7 in thread
On 2008-04-29 17:05:54 +0200, "Yan Shapochnik" <shapochniky@xxxxxxxxxxx> said:
> Hello Trenton,
>
> Thanks again for your follow up on this. Just to revisit what I had
> previosuly stated.... couldn't this be accomplished using notifications?
> If Qt uses the addObserver:selector:name:object: method to register an
> observer(s) and receive notifications of all kinds which are typically
> designated for NSApplication's delegate?
> Notifications trickle down to the observers similar in the way Carbon events
> are handled in a Carbon app. I am not familiar with all the details, but
> perhaps this could be a potential solution.
> What do you think?
It could work for most cases (such as activation). However, there are a
couple of methods that only are sent directly to the delegate (such as
asking if it can quit). We would only get a notification after the
fact; i.e. the app WILL quit.
> Do you have an idea when snapshot builds of Qt Cocoa will be available and
> posted by Trolltech?
Nothing official. The best I can say is we want to do it, we just need
to figure out the right way to get it out there. It will happen.
Hope this helps,
-- Trenton
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
