Community
Participate
Working Groups
As in bug 552063, macOS has changed the way in which the menu needs to be activated prior to running. Calling `activateWithOptions` in the main thread prevents menu items to be shown; instead, it should be called from the application's delegate applicationDidFinishLaunching callback, as per the investigation in https://stackoverflow.com/questions/62739862 Investigation is further needed, but removing the call to `[[NSRunningApplication currentApplication] activateWithOptions: NSApplicationActivateIgnoringOtherApps]; ` in eclipseCocoa.c may be sufficient; however, it may be that the early call is causing additional issues.
I assume this belongs to launcher.
Yes, it's here: https://github.com/eclipse/rt.equinox.framework/blob/0f05d756e18ceeee138e505de253bcfd36093167/features/org.eclipse.equinox.executable.feature/library/cocoa/eclipseCocoa.c#L103-L104
Once we've got bug 552063 merged, I can take a look at this and see what needs to be done in order to fix the launcher on macOS as well.
The blocking bug has been merged so I can look at this. Are there instructions on how I can build the Equinox launcher for macOS?
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/175929
Gerrit change https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/175929 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=cf46dda89155f53d2a14b300122479d3f3b6fb3d
Thanks for fixing this, Alex!
Verified fixed in I20210211-1810
NB when launching the app from the command line (e.g. Eclipse.app/Contents/MacOS/eclipse) doesn't show the splash screen at the front and/or the workspace choosing dialog - they have to be clicked to activate. When double-clicking the Eclipse.app (or using 'open Eclipse.app') the application is brought to the foreground as expected. I'm recording this observation here in case there's automation that requires on the application splash screen or workspace chosing dialog to the front, though I expect that such tools will be called with an explicit -data argument. When an explicit -data argument is supplied, the application does bring the splash screen to the front after it successfully launches.
(In reply to Alex Blewitt from comment #9) > NB when launching the app from the command line (e.g. > Eclipse.app/Contents/MacOS/eclipse) doesn't show the splash screen at the > front and/or the workspace choosing dialog - they have to be clicked to > activate. > > When double-clicking the Eclipse.app (or using 'open Eclipse.app') the > application is brought to the foreground as expected. > > I'm recording this observation here in case there's automation that requires > on the application splash screen or workspace chosing dialog to the front, > though I expect that such tools will be called with an explicit -data > argument. > > When an explicit -data argument is supplied, the application does bring the > splash screen to the front after it successfully launches. Hi Alex, Thanks for adding this note here. Why does this happen when launching from command line? I think launching eclipse from command line (without the data argument) is common use case and we shouldn't break it.
It's not broken as such; the splash screen is still displayed as is the workspace dialog, but the fix here (which removes the bring-to-front functionality) needs to be handled by the application start up handler, which is called after the dialog choice is shown. We could move it to the latter. It's incredibly rare for macOS applications to be launched on the command line; most people won't know how to do it, or will just use 'open' on the Eclipse.app, which will continue to work as expected. Running Eclipse.app/Contents/MacOS/eclipse still works, and you can click on the launch selection dialog and enter the location as expected; you can also pass -data and it will work as before. Once the choose-your-own-adventure workspace dialog is dismissed, the splash screen comes to the front again. In any case, if you've chosen the dialog and done the 'remember this for next time' checkbox it won't be a problem either. The majority of Eclipse users will never notice any difference here but will notice the difference in the launch from an Eclipse app or other RCPs. If this causes a significant issue and we need to investigate it further, one option would be to have an additional flag for macOS that triggers the behaviour before which is encoded in the eclipse.ini but not in the PDE launch, or vice versa. There's also a possibility that we could look into another approach of when/where/how the workspace chooser dialog is shown.
