Community
Participate
Working Groups
OS X 10.9.1 Eclipse 4.4 I20140115-1300 When launching an RCP application from Eclipse the RCP's application menu is initially not shown unless focus is lost then regained. 1. Using the inbuilt wizard, create a new Plug-in Project. 2. Ensure "This plug-in will make contributions to the UI" is checked. 3. Ensure "Would you like to create a 3.x rich client application?" is set to "Yes". 4. Choose the "RCP Mail Template" template. 5. Run As Eclipse Application. Expected Result: The RCP app's menu bar should show immediately in the OS X menu bar when the app is launched from Eclipse. Actual Result: The menu bar from Eclipse shows. If you click away from the RCP app (lose focus) and reselect the app, then the menu bar appears.
Tested on latest I build, same behaviour.
Is anyone else seeing this?
Still here in latest I build. Surely someone else must have noticed this?
This is really making it hard to develop in Eclipse 4.4 on a Mac. Could someone at least give me a hint on how I might go about fixing it, or a workaround?
I don't have any suggestions. Resetting the assignee to move to Platform UI.
Reassigning to SWT as I can reproduce this bug with a simple SWT app: public class Main { public static void main(String[] args) { Display d = Display.getDefault(); Shell shell = new Shell(d, SWT.SHELL_TRIM); shell.open(); while (!d.isDisposed()) { if (!d.readAndDispatch()) { d.sleep(); } } } } Switching between windows of the same app doesn't help — need to switch to a different app and back.
This problem is specific to OS X 10.9(.2?). I tried the little test program on OS X 10.8 running in a VM and the problem does not occur.
(In reply to Brian de Alwis from comment #6) > Reassigning to SWT as I can reproduce this bug with a simple SWT app: > > public class Main { > public static void main(String[] args) { > Display d = Display.getDefault(); > Shell shell = new Shell(d, SWT.SHELL_TRIM); > > shell.open(); > while (!d.isDisposed()) { > if (!d.readAndDispatch()) { > d.sleep(); > } > } > } > } > > Switching between windows of the same app doesn't help — need to switch to a > different app and back. Thanks for devising that test and investigating. Much appreciated. :-)
Same behavior with standalone SWT applications. See bug 427212 https://bugs.eclipse.org/bugs/show_bug.cgi?id=427212
Does no-one develop on Mac any more?
*** Bug 427212 has been marked as a duplicate of this bug. ***
Am I right thinking that the fix has been postponed a year when target milestone was set to 4.5? In a year from now Java 6, the only one we can use today on Mac OS X, will be too old.
(In reply to Rodolfo M. Raya from comment #12) > Am I right thinking that the fix has been postponed a year when target > milestone was set to 4.5? > > In a year from now Java 6, the only one we can use today on Mac OS X, will > be too old. This will be fixed in the 4.4.1 service release of Luna (along with 4.5), will re-target once the 4.4.1 target milestone is created in bugzilla.
*** Bug 435842 has been marked as a duplicate of this bug. ***
*** Bug 437590 has been marked as a duplicate of this bug. ***
Still present in 4.4.1 RC1
For information - also occurs on OS X Yosemite 10.10 beta 6. Does anyone know where to start looking in the code to investigate the problem?
(In reply to Phillipus B from comment #17) > For information - also occurs on OS X Yosemite 10.10 beta 6. > > Does anyone know where to start looking in the code to investigate the > problem? Get any of swt menu snippets from https://www.eclipse.org/swt/snippets/
(In reply to Sergiy G from comment #18) > (In reply to Phillipus B from comment #17) > > For information - also occurs on OS X Yosemite 10.10 beta 6. > > > > Does anyone know where to start looking in the code to investigate the > > problem? > > Get any of swt menu snippets from https://www.eclipse.org/swt/snippets/ That does not answer the question. To make it clearer - where in the Eclipse code might the problem be so we can take a look at it?
(In reply to Phillipus B from comment #19) > (In reply to Sergiy G from comment #18) > > (In reply to Phillipus B from comment #17) > > > For information - also occurs on OS X Yosemite 10.10 beta 6. > > > > > > Does anyone know where to start looking in the code to investigate the > > > problem? > > > > Get any of swt menu snippets from https://www.eclipse.org/swt/snippets/ > > That does not answer the question. To make it clearer - where in the Eclipse > code might the problem be so we can take a look at it? The problem is in the Display class. The variable that controls whether the program is up and running and menu painting is required is not properly initialized the first time. I traced the problem but had to abandon my investigation because I couldn't build an SWT jar (I don't know how to configure my system for building SWT). If someone tells me how to build SWT on Mac OS X, I could provide a patch. Regards, Rodolfo
(In reply to Rodolfo M. Raya from comment #20) > > The problem is in the Display class. The variable that controls whether the > program is up and running and menu painting is required is not properly > initialized the first time. > > I traced the problem but had to abandon my investigation because I couldn't > build an SWT jar (I don't know how to configure my system for building SWT). > > If someone tells me how to build SWT on Mac OS X, I could provide a patch. Are you talking about the native component, or the java component? PW
(In reply to Paul Webster from comment #21) > (In reply to Rodolfo M. Raya from comment #20) > > > > The problem is in the Display class. The variable that controls whether the > > program is up and running and menu painting is required is not properly > > initialized the first time. > > > > I traced the problem but had to abandon my investigation because I couldn't > > build an SWT jar (I don't know how to configure my system for building SWT). > > > > If someone tells me how to build SWT on Mac OS X, I could provide a patch. > > Are you talking about the native component, or the java component? > > PW I couldn't make an SWT jar because I didn't know how to setup Eclipse for building the Java component + the native part. The available documentation is not complete or updated enough.
(In reply to Rodolfo M. Raya from comment #20) > I traced the problem but had to abandon my investigation because I couldn't > build an SWT jar (I don't know how to configure my system for building SWT). > > If someone tells me how to build SWT on Mac OS X, I could provide a patch. > Here is the link to setup SWT from git -- http://eclipse.org/swt/git.php If there are only java changes, you don't have to build swt.jar. If there are native changes you have to rebuild the native libraries -- http://eclipse.org/swt/faq.php#howbuilddll how to build the swt.jar -- http://eclipse.org/swt/faq.php#howbuildjar
(In reply to Lakshmi Shanmugam from comment #23) > (In reply to Rodolfo M. Raya from comment #20) > > > I traced the problem but had to abandon my investigation because I couldn't > > build an SWT jar (I don't know how to configure my system for building SWT). > > > > If someone tells me how to build SWT on Mac OS X, I could provide a patch. > > > Here is the link to setup SWT from git -- http://eclipse.org/swt/git.php > If there are only java changes, you don't have to build swt.jar. > If there are native changes you have to rebuild the native libraries -- > http://eclipse.org/swt/faq.php#howbuilddll > > how to build the swt.jar -- http://eclipse.org/swt/faq.php#howbuildjar Thanks. I already saw those documents and used them in my attempt to fix the issue. I had no luck on building the jar locally. I need to build a jar for deploying my apps, even if the problem is only in the Java part.
(In reply to Rodolfo M. Raya from comment #24) > > Thanks. I already saw those documents and used them in my attempt to fix the > issue. I had no luck on building the jar locally. > > I need to build a jar for deploying my apps, even if the problem is only in > the Java part. You might be able to use maven to build the swt java jar and package the native fragment ... I'm just running a test to make sure. PW
(In reply to Rodolfo M. Raya from comment #24) > (In reply to Lakshmi Shanmugam from comment #23) > > (In reply to Rodolfo M. Raya from comment #20) > > > > > I traced the problem but had to abandon my investigation because I couldn't > > > build an SWT jar (I don't know how to configure my system for building SWT). > > > > > > If someone tells me how to build SWT on Mac OS X, I could provide a patch. > > > > > Here is the link to setup SWT from git -- http://eclipse.org/swt/git.php > > If there are only java changes, you don't have to build swt.jar. > > If there are native changes you have to rebuild the native libraries -- > > http://eclipse.org/swt/faq.php#howbuilddll > > > > how to build the swt.jar -- http://eclipse.org/swt/faq.php#howbuildjar > > Thanks. I already saw those documents and used them in my attempt to fix the > issue. I had no luck on building the jar locally. > > I need to build a jar for deploying my apps, even if the problem is only in > the Java part. What problems do you face while building the jar? Do you get any errors?
(In reply to Lakshmi Shanmugam from comment #26) > (In reply to Rodolfo M. Raya from comment #24) > > (In reply to Lakshmi Shanmugam from comment #23) > > > (In reply to Rodolfo M. Raya from comment #20) > > > > > > > I traced the problem but had to abandon my investigation because I couldn't > > > > build an SWT jar (I don't know how to configure my system for building SWT). > > > > > > > > If someone tells me how to build SWT on Mac OS X, I could provide a patch. > > > > > > > Here is the link to setup SWT from git -- http://eclipse.org/swt/git.php > > > If there are only java changes, you don't have to build swt.jar. > > > If there are native changes you have to rebuild the native libraries -- > > > http://eclipse.org/swt/faq.php#howbuilddll > > > > > > how to build the swt.jar -- http://eclipse.org/swt/faq.php#howbuildjar > > > > Thanks. I already saw those documents and used them in my attempt to fix the > > issue. I had no luck on building the jar locally. > > > > I need to build a jar for deploying my apps, even if the problem is only in > > the Java part. > > What problems do you face while building the jar? Do you get any errors? That happened about two months ago and I don't remember the details. I'm cloning Git repositories again now to restart my investigations.
(In reply to Lakshmi Shanmugam from comment #26) > (In reply to Rodolfo M. Raya from comment #24) > > (In reply to Lakshmi Shanmugam from comment #23) > > > (In reply to Rodolfo M. Raya from comment #20) > > > > > > > I traced the problem but had to abandon my investigation because I couldn't > > > > build an SWT jar (I don't know how to configure my system for building SWT). > > > > > > > > If someone tells me how to build SWT on Mac OS X, I could provide a patch. > > > > > > > Here is the link to setup SWT from git -- http://eclipse.org/swt/git.php > > > If there are only java changes, you don't have to build swt.jar. > > > If there are native changes you have to rebuild the native libraries -- > > > http://eclipse.org/swt/faq.php#howbuilddll > > > > > > how to build the swt.jar -- http://eclipse.org/swt/faq.php#howbuildjar > > > > Thanks. I already saw those documents and used them in my attempt to fix the > > issue. I had no luck on building the jar locally. > > > > I need to build a jar for deploying my apps, even if the problem is only in > > the Java part. > > What problems do you face while building the jar? Do you get any errors? I cloned "master" branch and built SWT jar for 64 bit cocoa. Got this error when I used the newly built jar in my apps: Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons: no swt-cocoa-4503 in java.library.path no swt-cocoa in java.library.path Can't load library: /Users/rmraya/.swt/lib/macosx/x86_64/libswt-cocoa-4503.jnilib Can't load library: /Users/rmraya/.swt/lib/macosx/x86_64/libswt-cocoa.jnilib at org.eclipse.swt.internal.Library.loadLibrary(Library.java:327) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:236) at org.eclipse.swt.internal.C.<clinit>(C.java:21) at org.eclipse.swt.widgets.Display.<clinit>(Display.java:102) at com.maxprograms.mvc.Swordfish.main(Swordfish.java:52)
Trying to build binaries following http://eclipse.org/swt/faq.php#howbuilddll I get this: ========================== Mini:library rmraya$ sh build.sh cc -c -xobjective-c -Wall -arch i386 -arch ppc -DSWT_VERSION=4503 -DUSE_ASSEMBLER -DCOCOA -DATOMIC -I /System/Library/Frameworks/JavaVM.framework/Headers -I /System/Library/Frameworks/Cocoa.framework/Headers -I /System/Library/Frameworks/JavaScriptCore.framework/Headers swt.c In file included from swt.c:12: ./swt.h:23:10: fatal error: 'jni.h' file not found #include "jni.h" ^ 1 error generated. In file included from swt.c:12: ./swt.h:23:10: fatal error: 'jni.h' file not found #include "jni.h" ^ 1 error generated. make: *** [swt.o] Error 1 ========================== There is no environment variable for JDK in build.sh that I can set. build.sh references XULRUNNER_SDK and sets a default location as: export XULRUNNER24_SDK="/Users/Shared/xulrunner/24-64/xulrunner-sdk/" but XulRunner is not there and I think I don't have XulRunner SDK. BTW, the need for XulRunner SDK is not documented.
The path to Java headers is wrong in org.eclipse.swt/bin/library/make_macosx.mak That make file was created for older versions of Mac OS X, probably 10.5, and does not work with OS X 10.9.4 Has the SWT Team compiled SWT on Mac OS X Mavericks?
(In reply to Rodolfo M. Raya from comment #28) > I cloned "master" branch and built SWT jar for 64 bit cocoa. > > Got this error when I used the newly built jar in my apps: > > Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not load > SWT library. Reasons: > no swt-cocoa-4503 in java.library.path > no swt-cocoa in java.library.path > Can't load library: > /Users/rmraya/.swt/lib/macosx/x86_64/libswt-cocoa-4503.jnilib > Can't load library: /Users/rmraya/.swt/lib/macosx/x86_64/libswt-cocoa.jnilib > > at org.eclipse.swt.internal.Library.loadLibrary(Library.java:327) > at org.eclipse.swt.internal.Library.loadLibrary(Library.java:236) > at org.eclipse.swt.internal.C.<clinit>(C.java:21) > at org.eclipse.swt.widgets.Display.<clinit>(Display.java:102) > at com.maxprograms.mvc.Swordfish.main(Swordfish.java:52) Are you able to launch a simple SWT snippet from your workspace with the changes? How are you using the jar? The error usually happens when the version of the native libraries is different from the version in Library.java.
(In reply to Rodolfo M. Raya from comment #30) > The path to Java headers is wrong in > > org.eclipse.swt/bin/library/make_macosx.mak > > That make file was created for older versions of Mac OS X, probably 10.5, > and does not work with OS X 10.9.4 > > Has the SWT Team compiled SWT on Mac OS X Mavericks? SWT currently builds on OSX 10.5. I was able to build libraries without any problem on 10.8. Building libraries on Mavericks may require some changes. That said, if you have java only changes you don't have to rebuild the libraries. If you have a patch with a fix, you can post it here so that others could test it.
(In reply to Lakshmi Shanmugam from comment #31) > (In reply to Rodolfo M. Raya from comment #28) > > > I cloned "master" branch and built SWT jar for 64 bit cocoa. > > > > Got this error when I used the newly built jar in my apps: > > > > Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not load > > SWT library. Reasons: > > no swt-cocoa-4503 in java.library.path > > no swt-cocoa in java.library.path > > Can't load library: > > /Users/rmraya/.swt/lib/macosx/x86_64/libswt-cocoa-4503.jnilib > > Can't load library: /Users/rmraya/.swt/lib/macosx/x86_64/libswt-cocoa.jnilib > > > > at org.eclipse.swt.internal.Library.loadLibrary(Library.java:327) > > at org.eclipse.swt.internal.Library.loadLibrary(Library.java:236) > > at org.eclipse.swt.internal.C.<clinit>(C.java:21) > > at org.eclipse.swt.widgets.Display.<clinit>(Display.java:102) > > at com.maxprograms.mvc.Swordfish.main(Swordfish.java:52) > > Are you able to launch a simple SWT snippet from your workspace with the > changes? > How are you using the jar? The error usually happens when the version of the > native libraries is different from the version in Library.java. I can run SWT snippets and my own test projects from within Eclipse. The generated jar does not include binariees, so the Ant scrip is wrong. I manually added the binary part to the jar and was able to run my code outside Eclipse. The project that generates binaries is outdated. It was designed for OS X 10.5, five versions old by now. There are several issues in the Java part: - createMainMenu() is never called in Display class. Actually, this method could be deleted and there would be no impact (I verified this). - setMenuBar(Menu menu) in Display class does not complete, it exits prematurely because "appMenuBar" is always null. - forceFocus() in Control class is wrong. It asumes that notifications of display activation are fired automatically in Cocoa and that Display catches them in readAndDispatch(). This is no longer the case in OS X 10.9. - It seems that Shell is actually forcing the display of the menu when re-acquiring focus after switching applications. If this is true, it means that current logic for creating menus from Display class needs to be changed.
(In reply to Lakshmi Shanmugam from comment #32) > > SWT currently builds on OSX 10.5. I was able to build libraries without any > problem on 10.8. Building libraries on Mavericks may require some changes. The problem is that the code that works on 10.5 or 10.8 fails on 10.9 and 10.10
(In reply to Rodolfo M. Raya from comment #34) > (In reply to Lakshmi Shanmugam from comment #32) > > > > SWT currently builds on OSX 10.5. I was able to build libraries without any > > problem on 10.8. Building libraries on Mavericks may require some changes. > > The problem is that the code that works on 10.5 or 10.8 fails on 10.9 and > 10.10 Thanks for looking at this problem. Is it at the "blocked" stage now?
(In reply to Phil Beauvoir from comment #35) > (In reply to Rodolfo M. Raya from comment #34) > > (In reply to Lakshmi Shanmugam from comment #32) > > > > > > SWT currently builds on OSX 10.5. I was able to build libraries without any > > > problem on 10.8. Building libraries on Mavericks may require some changes. > > > > The problem is that the code that works on 10.5 or 10.8 fails on 10.9 and > > 10.10 > > Thanks for looking at this problem. Is it at the "blocked" stage now? The C code that displays the menu works fine on 10.8 but fails on 10.9 and 10.10. I can't fix the C code (don't know how). Regards, Rodolfo
Target milestone changed to 4.5. :-( I'm trying to find developers who may be able to help fix the problem, but I'm failing. I'm sure that there are some Eclipse users who are using Macs these days.
(In reply to Phil Beauvoir from comment #37) > Target milestone changed to 4.5. :-( > > I'm trying to find developers who may be able to help fix the problem, but > I'm failing. > > I'm sure that there are some Eclipse users who are using Macs these days. It seems that we will have to live with this bug for another year due to the change in target milestone. Right now the only way to deploy an SWT-based application or RCP application on a Mac is using Java 1.6 with JavaApplicationStub. Apple doesn't support Java 1.6 anymore and I don't know if it will be available when Yosemite ((OS X 10.10) is released. It is a shame that we can't develop for Java 1.7 or Java 1.8 if we deploy on OS X. I'll try again to fix the issue, but it seems that we will need a version of SWT for OS X 10.8 and a different one for OS X 10.9 and 10.10
(In reply to Rodolfo M. Raya from comment #38) > (In reply to Phil Beauvoir from comment #37) > > Target milestone changed to 4.5. :-( > > > > I'm trying to find developers who may be able to help fix the problem, but > > I'm failing. > > > > I'm sure that there are some Eclipse users who are using Macs these days. > > It seems that we will have to live with this bug for another year due to the > change in target milestone. > > Right now the only way to deploy an SWT-based application or RCP application > on a Mac is using Java 1.6 with JavaApplicationStub. > > Apple doesn't support Java 1.6 anymore and I don't know if it will be > available when Yosemite ((OS X 10.10) is released. > > It is a shame that we can't develop for Java 1.7 or Java 1.8 if we deploy on > OS X. > > I'll try again to fix the issue, but it seems that we will need a version of > SWT for OS X 10.8 and a different one for OS X 10.9 and 10.10 I wonder if it implies a bigger issue - that there are not enough resources/developers to support Mac OS X on SWT any more. I'm not trying to be negative or cast blame. Just wondering.
(In reply to Phil Beauvoir from comment #39) > I wonder if it implies a bigger issue - that there are not enough > resources/developers to support Mac OS X on SWT any more. I'm not trying to > be negative or cast blame. Just wondering. Oh, there are quite a few of us developing on OS X. I guess most have been ignoring the issue as I have. Thank you for bringing it up. I'm no Cocoa developer myself but I do have some colleagues to lean on. So I'll have a look.
(In reply to Torkild U. Resheim from comment #40) > (In reply to Phil Beauvoir from comment #39) > > I wonder if it implies a bigger issue - that there are not enough > > resources/developers to support Mac OS X on SWT any more. I'm not trying to > > be negative or cast blame. Just wondering. > Oh, there are quite a few of us developing on OS X. I guess most have been > ignoring the issue as I have. Thank you for bringing it up. I'm no Cocoa > developer myself but I do have some colleagues to lean on. So I'll have a > look. :-) And I will ask my colleagues, too. Thanks!
(In reply to Rodolfo M. Raya from comment #38) > Right now the only way to deploy an SWT-based application or RCP application > on a Mac is using Java 1.6 with JavaApplicationStub. > > Apple doesn't support Java 1.6 anymore and I don't know if it will be > available when Yosemite ((OS X 10.10) is released. It is still available and appears to be still supported. Works nicely on Yosemite as far as I can tell. http://support.apple.com/kb/DL1572?viewlocale=en_US&locale=en_US > > It is a shame that we can't develop for Java 1.7 or Java 1.8 if we deploy on > OS X. I believe you can. I'm running Eclipse 4.4 on Java 1.8 on Yosemite.
(In reply to Torkild U. Resheim from comment #42) > (In reply to Rodolfo M. Raya from comment #38) > > Right now the only way to deploy an SWT-based application or RCP application > > on a Mac is using Java 1.6 with JavaApplicationStub. > > > > Apple doesn't support Java 1.6 anymore and I don't know if it will be > > available when Yosemite ((OS X 10.10) is released. > It is still available and appears to be still supported. Works nicely on > Yosemite as far as I can tell. > http://support.apple.com/kb/DL1572?viewlocale=en_US&locale=en_US > > > > It is a shame that we can't develop for Java 1.7 or Java 1.8 if we deploy on > > OS X. > I believe you can. I'm running Eclipse 4.4 on Java 1.8 on Yosemite. But you can't deploy. Eclipse 4.4 runs fine on Java 1.8 but applications that you develop using SWT cannot run using Java 1.8 without exhibiting the menu problem. The only workaround for the missing menu is using JavaApplicationStub & Java 1.6
(In reply to Torkild U. Resheim from comment #42) > (In reply to Rodolfo M. Raya from comment #38) > > Right now the only way to deploy an SWT-based application or RCP application > > on a Mac is using Java 1.6 with JavaApplicationStub. > > > > Apple doesn't support Java 1.6 anymore and I don't know if it will be > > available when Yosemite ((OS X 10.10) is released. > It is still available and appears to be still supported. Works nicely on > Yosemite as far as I can tell. > http://support.apple.com/kb/DL1572?viewlocale=en_US&locale=en_US > > > > It is a shame that we can't develop for Java 1.7 or Java 1.8 if we deploy on > > OS X. > I believe you can. I'm running Eclipse 4.4 on Java 1.8 on Yosemite. Yes, so am I. :-) Let's not lose sight of the issue here - it's actually more of an annoyance when developing and testing when launching a second instance of Eclipse or an RCP app from the first Eclipse version.
(In reply to Phil Beauvoir from comment #44) > (In reply to Torkild U. Resheim from comment #42) > > (In reply to Rodolfo M. Raya from comment #38) > > > It is a shame that we can't develop for Java 1.7 or Java 1.8 if we deploy on > > > OS X. > > I believe you can. I'm running Eclipse 4.4 on Java 1.8 on Yosemite. > > Yes, so am I. :-) > > Let's not lose sight of the issue here - it's actually more of an annoyance > when developing and testing when launching a second instance of Eclipse or > an RCP app from the first Eclipse version. It is not just an annoyance when developing. I can live with that. It is a serious problem when you need to deploy an application that uses SWT to display its GUI. Users would not accept having to click outside the application and then switch back to the program just to see the menu.
(In reply to Rodolfo M. Raya from comment #45) > (In reply to Phil Beauvoir from comment #44) > > (In reply to Torkild U. Resheim from comment #42) > > > (In reply to Rodolfo M. Raya from comment #38) > > > > It is a shame that we can't develop for Java 1.7 or Java 1.8 if we deploy on > > > > OS X. > > > I believe you can. I'm running Eclipse 4.4 on Java 1.8 on Yosemite. > > > > Yes, so am I. :-) > > > > Let's not lose sight of the issue here - it's actually more of an annoyance > > when developing and testing when launching a second instance of Eclipse or > > an RCP app from the first Eclipse version. > > It is not just an annoyance when developing. I can live with that. > > It is a serious problem when you need to deploy an application that uses SWT > to display its GUI. Users would not accept having to click outside the > application and then switch back to the program just to see the menu. Sorry, that's my misunderstanding. I only see it in development. Once my app is a standalone RCP app the issue is not there. I guess you are seeing it in a SWT type app?
(In reply to Phil Beauvoir from comment #46) > (In reply to Rodolfo M. Raya from comment #45) > > (In reply to Phil Beauvoir from comment #44) > > > (In reply to Torkild U. Resheim from comment #42) > > > > (In reply to Rodolfo M. Raya from comment #38) > > > > It is not just an annoyance when developing. I can live with that. > > > > It is a serious problem when you need to deploy an application that uses SWT > > to display its GUI. Users would not accept having to click outside the > > application and then switch back to the program just to see the menu. > > Sorry, that's my misunderstanding. I only see it in development. Once my app > is a standalone RCP app the issue is not there. I guess you are seeing it in > a SWT type app? Yes, it appears in SWT type apps deployed on OS X 10.9. And it is really bad.
(In reply to Rodolfo M. Raya from comment #47) > (In reply to Phil Beauvoir from comment #46) > > (In reply to Rodolfo M. Raya from comment #45) > > > (In reply to Phil Beauvoir from comment #44) > > > > (In reply to Torkild U. Resheim from comment #42) > > > > > (In reply to Rodolfo M. Raya from comment #38) > > > > > > > It is not just an annoyance when developing. I can live with that. > > > > > > It is a serious problem when you need to deploy an application that uses SWT > > > to display its GUI. Users would not accept having to click outside the > > > application and then switch back to the program just to see the menu. > > > > Sorry, that's my misunderstanding. I only see it in development. Once my app > > is a standalone RCP app the issue is not there. I guess you are seeing it in > > a SWT type app? > > Yes, it appears in SWT type apps deployed on OS X 10.9. > > And it is really bad. I can confirm that RCP applications work fine. The bug is present on standalone SWT applications. I think that the bug description is wrong and needs to be updated. Regards, Rodolfo
> I can confirm that RCP applications work fine. > > The bug is present on standalone SWT applications. > > I think that the bug description is wrong and needs to be updated. > > Regards, > Rodolfo That is not quite correct. RCP applications work fine when they are deployed as standalone applications. But the menu problem exist when you are developing the RCP application and launching it from Eclipse. That is why the bug title is "RCP application menu not shown when launched from Eclipse"
> The only workaround for the missing menu is using JavaApplicationStub & Java > 1.6 I am using a swt application with java 1.6 and have the same problem. But I am using a shell-skript and not JavaApplicationStub to start it.
JavaFX had the same problem with OS X 10.9 and now it is fixed on Java 8. See https://javafx-jira.kenai.com/browse/RT-33881 I tested JavaFX with Java 1.8_u20 and the menu is painted when the application is launched. No need to switch focus to another app and back.
(In reply to Rodolfo M. Raya from comment #51) > JavaFX had the same problem with OS X 10.9 and now it is fixed on Java 8. > > See https://javafx-jira.kenai.com/browse/RT-33881 > > I tested JavaFX with Java 1.8_u20 and the menu is painted when the > application is launched. No need to switch focus to another app and back. OK, but I'm running Java 1.8_u20 and I still see the problem as I originally described it.
Still the same problem with swt standalone application, java 1.8.25, swt 4.4 cocoa 64bit. I am starting the application with a startscript.
(In reply to andreas from comment #53) > Still the same problem with swt standalone application, java 1.8.25, swt 4.4 > cocoa 64bit. I am starting the application with a startscript. Sounds interesting, what is the script?
(In reply to andreas from comment #53) > Still the same problem with swt standalone application, java 1.8.25, swt 4.4 > cocoa 64bit. I am starting the application with a startscript. The bug is still present in Yosemite (OS X 10.10) with Java 1.8_u40. SWT-based apps start without displaying the menu.
(In reply to Phil Beauvoir from comment #54) > (In reply to andreas from comment #53) > > Still the same problem with swt standalone application, java 1.8.25, swt 4.4 > > cocoa 64bit. I am starting the application with a startscript. > > Sounds interesting, what is the script? hi phil, the java call in the script looks like: ./java/macosx64/bin/java -Xdock:name="eabirdMacOSX" -Xdock:icon=./eabird/icons/logo256.png -jar ./eabird/start.jar in "./java/macosx64/" is the contents of jre1.8.25.jre/Contents/Home of jre-8u25-macosx-x64.tar.gz ./eabird/start.jar is my launcher which calls the same java version with the -Xms and -Xmx parameters and -XstartOnFirstThread, -Dorg.eclipse.swt.internal.carbon.noFocusRing -Dorg.eclipse.swt.internal.carbon.smallFonts -Xdock:name=eabirdMacOSX , the classpath with all needed jar files and the main class of the application. the launcher also shows a awt splash screen. I will try to remove the carbon parameters.
same effect without my launcher. if i am calling java (1.8.25) in the terminal with java -XstartOnFirstThread -cp ALLMYJARS MAINCLASS i am getting my application window and it gets the focus but the menu is still the menu from the terminal application.
and also with the swt version of the current swt-4.4.1-cocoa-macosx-x86_64.zip
And still the same with Snippet29 and swt-4.5M3-cocoa-macosx-x86_64.
Rodolfo did a lot of work identifying the problem.
(In reply to Phil Beauvoir from comment #60) > Rodolfo did a lot of work identifying the problem. As far as I was able to tell, the problem is in the binary part. Something changed in the Cocoa library released by Apple and the binaries shipped with SWT were not updated accordingly. When an application is created, the calls to Cocoa for displaying the menu fail. The calls to refresh the menu when the application regains focus after loosing it work fine.
ok, so the only way is fixing the binary :(
Ok, I debugged the cocoa swt and I think I could localize the problem. It's in the method Display.createDisplay (DeviceData data): OS.SetFrontProcess() is called to early or an event must be consumed before the call. If I change OS.TransformProcessType (psn, OS.kProcessTransformToForegroundApplication); OS.SetFrontProcess (psn); to: OS.TransformProcessType (psn, OS.kProcessTransformToForegroundApplication); application.nextEventMatchingMask(0, null, OS.NSDefaultRunLoopMode, true); OS.SetFrontProcess (psn); then the menu is shown as expected.
(In reply to andreas from comment #63) > Ok, I debugged the cocoa swt and I think I could localize the problem. It's > in the method Display.createDisplay (DeviceData data): > > OS.SetFrontProcess() is called to early or an event must be consumed before > the call. > > If I change > OS.TransformProcessType (psn, OS.kProcessTransformToForegroundApplication); > OS.SetFrontProcess (psn); > > to: > OS.TransformProcessType (psn, OS.kProcessTransformToForegroundApplication); > application.nextEventMatchingMask(0, null, OS.NSDefaultRunLoopMode, true); > OS.SetFrontProcess (psn); > > then the menu is shown as expected. That's great news! Would it be possible to submit a patch or for someone to do this?
I don't know what the sideeffect of the consuming of this event is (and also how to make a correct patch). So I hope someone of the mac-developers could check it.
(In reply to Phil Beauvoir from comment #64) > > That's great news! Would it be possible to submit a patch or for someone to > do this? Now I was able to make a 64bit cocoa jar file, but only without xulrunner libs. If you don't need xulrunner then you could try my version. you will find it here: http://http://eabird.at/demos/v1.107/org.eclipse.swt.cocoa.macosx.x86_64_3.104.0.jar
(In reply to andreas from comment #66) > Now I was able to make a 64bit cocoa jar file, but only without xulrunner > libs. If you don't need xulrunner then you could try my version. you will > find it here: > http://http://eabird.at/demos/v1.107/org.eclipse.swt.cocoa.macosx.x86_64_3. > 104.0.jar I tried your jar in one of my apps and the menu is displayed as it should. Thanks a lot! Rodolfo
(In reply to andreas from comment #66) > (In reply to Phil Beauvoir from comment #64) > > > > That's great news! Would it be possible to submit a patch or for someone to > > do this? > > Now I was able to make a 64bit cocoa jar file, but only without xulrunner > libs. If you don't need xulrunner then you could try my version. you will > find it here: > http://http://eabird.at/demos/v1.107/org.eclipse.swt.cocoa.macosx.x86_64_3. > 104.0.jar It's good to see it work. The longer term solution is to see the fix committed in code. I wonder, though, with this bug and other SWT bugs not being fixed, whether SWT is supported on OS X any more?
Created attachment 248969 [details] patch for bug 426062
> I wonder, though, with this bug and other SWT bugs not being fixed, whether > SWT is supported on OS X any more? I am also wondering, otherwise I see discussions on eclipse macosx topics on other bugs, so developers are existing ;) But I think they are a bit overloaded. And its not easy to get the swt development stuff running so its diffcult for others like me to be helpful. But I got it at least working now (except for the xulrunner stuff) and if someone needs help to get it also running I would like to help with the thinks I figured out last days. But I don't know where would be the right place to discuss this things? There is also a fundamental problem with the macosx port, specially with the habit of apple incompatibly changing the cocoa api. I think in the next years there must be a decision to stop supporting 10.5 (and maybe also 10.6) otherwise two native libraries are needed. and i don't see how this could be done in the current swt library structure.
(In reply to andreas from comment #70) > > There is also a fundamental problem with the macosx port, specially with the > habit of apple incompatibly changing the cocoa api. I think in the next > years there must be a decision to stop supporting 10.5 (and maybe also 10.6) > otherwise two native libraries are needed. and i don't see how this could be > done in the current swt library structure. Perhaps SWT should be left as a legacy toolkit and start migrating to JavaFX. I recently started testing JavaFX as an alternative. I also has bugs but they are being fixed faster. SWT developers that used to be active committers are now actively working on JavaFX development and commit their new code there. The e(fx)clipse project is slowly paving the road to a new JavaFX based version of Eclipse IDE. This could be a sign that times are changing. Regards, ROdolfo
(In reply to andreas from comment #70) > > And its not easy to get the swt development stuff running so its diffcult > for others like me to be helpful. But I got it at least working now (except > for the xulrunner stuff) and if someone needs help to get it also running I > would like to help with the thinks I figured out last days. But I don't know > where would be the right place to discuss this things? See Comment 23 for the links for setting up dev environment & build the libraries and jars. I think building the libraries works out of the box till 10.8, but requires some modifications on 10.9 & 10.10. If you have the steps/changes to make it work, I'll be happy to add them to the swt FAQ page.
(In reply to Lakshmi Shanmugam from comment #72) > (In reply to andreas from comment #70) > > > > > And its not easy to get the swt development stuff running so its diffcult > > for others like me to be helpful. But I got it at least working now (except > > for the xulrunner stuff) and if someone needs help to get it also running I > > would like to help with the thinks I figured out last days. But I don't know > > where would be the right place to discuss this things? > See Comment 23 for the links for setting up dev environment & build the > libraries and jars. I think building the libraries works out of the box till > 10.8, but requires some modifications on 10.9 & 10.10. If you have the > steps/changes to make it work, I'll be happy to add them to the swt FAQ page. But what difference will this make? Here is a proposed fix and patch...and.....then what? Will the patch be applied?
(In reply to andreas from comment #65) > I don't know what the sideeffect of the consuming of this event is (and also > how to make a correct patch). So I hope someone of the mac-developers could > check it. Thanks for investigating this, Andreas. I've tried your changes and they work for me. But, I'm investigating if we can stop using SetFrontProcess() (since its deprecated) and use the replacement methods from NSApplication or NSRunningApplication.
(In reply to Phil Beauvoir from comment #73) > But what difference will this make? The steps will be useful for anyone trying to setup a swt dev environment on 10.9. >Here is a proposed fix and > patch...and.....then what? Will the patch be applied? I've tried the proposed fix and it fixes the problem... but as mentioned above I'm investigating if we can have a slightly different solution.
(In reply to Lakshmi Shanmugam from comment #75) > (In reply to Phil Beauvoir from comment #73) > > > But what difference will this make? > The steps will be useful for anyone trying to setup a swt dev environment on > 10.9. > > >Here is a proposed fix and > > patch...and.....then what? Will the patch be applied? > I've tried the proposed fix and it fixes the problem... but as mentioned > above I'm investigating if we can have a slightly different solution. Thank-you. Sounds good.
> Thanks for investigating this, Andreas. I've tried your changes and they > work for me. But, I'm investigating if we can stop using SetFrontProcess() > (since its deprecated) and use the replacement methods from NSApplication or > NSRunningApplication. Yes, that would be a much better solution! I was also searching for a replacment, but didn't know how to find out which of this new methods will work on OSX 10.5 and what is the correct use of the tool MacGenerator (e.g. I did not know which of the items are also available on 10.5 when I am working on 10.9; is there a possibility to find out? reading the cocoa api docs of 10.5 (have you a link?) or must it be done on an mac with 10.5 installed?)
> See Comment 23 for the links for setting up dev environment & build the > libraries and jars. I think building the libraries works out of the box till > 10.8, but requires some modifications on 10.9 & 10.10. If you have the > steps/changes to make it work, I'll be happy to add them to the swt FAQ page. Yes the infos in your comment 23 did help a lot, but some points are missing. I will try to restart with a new clean macosx 10.9 or 10.10 and note all missing stuff I needed to be able to generate the jars. Here some problems which I remember: * missing stuff, like java header files and "command line tools for XCode" * I didn't have the latest eclipse version installed (release 4.2) * question: which java version should I use java 1.6 or java 1.5 (not working because classes like String have not been found?), header files I found have been from jdk 1.5 * that the default target in the build.xml of org.eclipse.swt.cocoa.macosx.x86_64 is build.update.jar and not build.jar. this leads to an build error until I uncommented "the line with <eclipse.versionReplacer...> in the build file buildFragement.xml of the project org.eclipse.swt Some problems came from not knowing egit (and also git not very well). (One problem I had now was: I wanted to throw away my local changes from eclipse.platform.swt.binaries, but the build.sha1 files are not set back to original master versions. I thought (hard) resetting the repository would do it (in the View "Git Repositories" I am selecting "eclipse.platform.swt.binaries", rigth click and in the popup menu I am selecting "Reset..."), but I needed to "Rebase..." it to get the build.sha1 files from the master versions.
(In reply to andreas from comment #78) > * question: which java version should I use java 1.6 or java 1.5 (not > working because classes like String have not been found?), header files I > found have been from jdk 1.5 Use Java 1.6. That's the only one supported by Apple at this moment. Java 7 and 8 are the ones supported by Oracle. None supports Java 5. Regards, Rodolfo
(In reply to andreas from comment #77) > > Thanks for investigating this, Andreas. I've tried your changes and they > > work for me. But, I'm investigating if we can stop using SetFrontProcess() > > (since its deprecated) and use the replacement methods from NSApplication or > > NSRunningApplication. > Yes, that would be a much better solution! > > I was also searching for a replacment, but didn't know how to find out which > of this new methods will work on OSX 10.5 and what is the correct use of the > tool MacGenerator (e.g. I did not know which of the items are also available > on 10.5 when I am working on 10.9; is there a possibility to find out? > reading the cocoa api docs of 10.5 (have you a link?) or must it be done on > an mac with 10.5 installed?) The mac generator tool gets the class & method information from the *Full.bridgesupport files in the project. The files were generated for 10.7 (so they have the APIs available in 10.7). To find what APIs are available in which version of OSX, you can use the online Apple API reference. It has options that lets you set the deployment target on the page & the documentation changes accordingly. For eg: This is the link to NSApplication reference --> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSApplication_Class/ Click on options and set the deployment target to 10.5. The page lists the methods available in 10.5
Created attachment 249715 [details] patch using NSRunningApplication SetFrontProcess() is deprecated and looks like it stopped working from 10.9. The patch uses NSApplication & NSRunningApplication APIs which are available from 10.6. I tried with standalone SWT snippets and the MenuBar appears as expected.
Will the patch make it into SWT?
We are considering this for 4.4.2. It doesn't seem to work while launching RCP application from eclipse. The behavior is same as with patch in comment 69. That patch too doesn't work while launching RCP app from eclipse. Can someone from the community try it out?
The fix is available in the latest I-build -- http://download.eclipse.org/eclipse/downloads/drops4/I20150106-0800/
(In reply to Lakshmi Shanmugam from comment #84) > The fix is available in the latest I-build -- > http://download.eclipse.org/eclipse/downloads/drops4/I20150106-0800/ I tried the latest I-build and launched my RCP application, but the problem is still there (as you say in Comment #83). What does this patch fix?
(In reply to Phil Beauvoir from comment #85) > (In reply to Lakshmi Shanmugam from comment #84) > > The fix is available in the latest I-build -- > > http://download.eclipse.org/eclipse/downloads/drops4/I20150106-0800/ > > I tried the latest I-build and launched my RCP application, but the problem > is still there (as you say in Comment #83). What does this patch fix? It fixes the problem for standalone SWT apps. Does the patch in comment 69 fix the problem for you?
(In reply to Lakshmi Shanmugam from comment #86) > (In reply to Phil Beauvoir from comment #85) > > (In reply to Lakshmi Shanmugam from comment #84) > > > The fix is available in the latest I-build -- > > > http://download.eclipse.org/eclipse/downloads/drops4/I20150106-0800/ > > > > I tried the latest I-build and launched my RCP application, but the problem > > is still there (as you say in Comment #83). What does this patch fix? > > It fixes the problem for standalone SWT apps. Does the patch in comment 69 > fix the problem for you? No, not when launching an RCP app.
pushed change to R4_4_maintenance branch --> http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R4_4_maintenance&id=4a240a98ea8c4dd6135c85e6bdf51e0a64847329
I still don't understand what you have fixed with this patch. It hasn't fixed the original bug that I reported - of launching an RCP app from Eclipse itself.
Hi Lakshmi, for my swt-menu-problem (standalone swt) the patch is working! I still had problems to create a correct swt.jar file (jnilib's have not been but into the jar, but this is an other story), therefore I am this late with my feedback. and phil sorry that your rcp-menu bug is not fixed with this patch. but I think its a good move to change to NSRunningApplication so maybe its the first step to fix also the rcp-menu problem.
(In reply to andreas from comment #90) > and phil sorry that your rcp-menu bug is not fixed with this patch. but I > think its a good move to change to NSRunningApplication so maybe its the > first step to fix also the rcp-menu problem. Sure, I'm not being ungrateful. :-) I'm just trying to understand what this fix does. What do you mean by "standalone swt"?
I am only using the swt.jar file in my application and create a shell and application window etc. without the rcp binding stuff.
The above commit fixes one part of the bug - the menu not being shown with standalone SWT applications. This is fixed in 4.5 master & 4.4.2. The remaining issue - RCP application menu not shown when launched from Eclipse, is not fixed and will be tracked by the cloned bug -- Bug 457921
Verified on build: I20141029-2000
(In reply to Lakshmi Shanmugam from comment #94) > Verified on build: I20141029-2000 Sorry, a correction, verified in build: I20150126-2000
It's a shame that this bug as originally decribed by me got transformed into a different bug, and my bug got transposed to a new one with no votes.
(In reply to Phil Beauvoir from comment #96) > It's a shame that this bug as originally decribed by me got transformed into > a different bug, and my bug got transposed to a new one with no votes. Sorry about this. The problem here is that this bug is tracking two different but related issues. The comments and votes and duplicate bugs are for either of the bugs and not for the RCP issue alone. I closed this bug because it had the discussion, patches & commit history for the issue that was fixed. Opening a new bug and moving everything would have been difficult. Note that the new bug is a clone of this bug and has all the people here in CC and reference to this bug. Please continue any discussion there, if required.
(In reply to Lakshmi Shanmugam from comment #97) > (In reply to Phil Beauvoir from comment #96) > > It's a shame that this bug as originally decribed by me got transformed into > > a different bug, and my bug got transposed to a new one with no votes. > > Sorry about this. > The problem here is that this bug is tracking two different but related > issues. The comments and votes and duplicate bugs are for either of the bugs > and not for the RCP issue alone. > I closed this bug because it had the discussion, patches & commit history > for the issue that was fixed. Opening a new bug and moving everything would > have been difficult. > Note that the new bug is a clone of this bug and has all the people here in > CC and reference to this bug. Please continue any discussion there, if > required. That's fair enough. :-)
Verified in build: M20150128-1000
*** Bug 525688 has been marked as a duplicate of this bug. ***
