• Type: Enhancement
• Component: javafx
• Sub-Component: window-toolkit
• Affected Version: fx2.1,9

• Priority: P4
• Status: Open
• Resolution: Unresolved

• Submitted: 2012-01-10
• Updated: 2018-09-05

Other
tbdUnresolved

BlueJ and Greenfoot are interested on this enhancement. Comment from them: """Apple APIs are going away, no suitable JavaFX replacement. A JavaFX application cannot receive Mac open-files event, meaning you can't reliably launch a JavaFX application by double-clicking an associated file. Work-around: Use an invasive call to access JDK internals, will not work with JDK 9 Jigsaw. """ 14-04-2017 As stated in http://openjdk.java.net/jeps/260, a replacement to this internal API has been provided [1] in JDK 9 and com.apple.eawt will be encapsulated. The command-line workaround to break encapsulation could be used before migrating to the new API. [1] http://openjdk.java.net/jeps/272 30-06-2016 Not part of the FX 8 PRD, consider for future release 23-04-2013 The only thing critical for SB in the 2.1 time frame is tracked by RT-18118. 24-01-2012 I just tried the API you added. This is fine when the SB is already running we do receive openFiles event. I am realizing that we need the openApplication event too in order to bootstrap the SB. The call should be : handleOpenApplication(ApplicationEvent event) JF 19-01-2012 > The Services menu is included in the default nib file created by Xcode and Interface Builder for Cocoa applications Most applications have this menu, even if all they do is have the default implementation that doesn't do much. It is not harmful to have it. 12-01-2012 Here is the doc describing Services: overview: http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/SysServices/Articles/overview.html implementation: http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/SysServices/Articles/using.html#//apple_ref/doc/uid/20000854-CEGDDHJJ Basically, this is something that app developer would need to explicitly ask by registering for services. The menu gets created automatically for such apps. We should not be adding this menu manually. If we do want to support Services, we would need Glass/JFX APIs that allow the developer to select the services they want. I don't think this is something we want to do unless we expose it on JFX level with dedicated APIs and mechanism. 12-01-2012 My understanding is that the standard nib that is generated by Xcode generates the Services menu (and Hide/Show items) and takes care of the implementation. Is this not the case? The problem with having the About XXX is that it requires an application specific implemenation and that needs FX API. Same with Preferences. Personally, I would like to see us add this API, but that is for another day. 12-01-2012 I assume those are Mac specific? "Services ->" seems for very specialized features supported by Mac apps. If we wanted to add that menu, we'd have to architecture some mechanism for JFX apps to participate in those service - seems elaborate. I can see the following menus are being useful: Hide XXX Hide Others Show All I am surprised we don't want to do "About XXX" with some default window though. What time frame you would like to see those menus added in? 12-01-2012 I spoke with Richard and Jasper today and we are leaning towards having this default: Services -> ---- Hide XXX Hide Others Show All ---- Quit XXX There would be no FX API to manipuate these items (yet). About+Preferences can't be added without some FX API to manipuate these items. 12-01-2012 You can do any menus you want using existing API. The question here is what menus should we install by default. 12-01-2012 The DesignerTool (Scene Buillder now) is not a NetBeans plugin. It is a standalone tool that will have a tight integration in NetBeans (perhaps in the incarnation of a plugin). We will need the About+Preferences menus for sure. 12-01-2012 As long we implement the corresponding callbacks for the default menus we want to install, we're ok. The developer can always remove those menus if they, for some reason, do not want them. Having those default menus installed automatically would correspond to Xcode providing a default app project, which does include does menus. In my opinion, however, only the "Quit" is absolutely necessary - as Mac users are accustom to easily quitting apps by hitting Quit shortcut, and it would be very confusing not to have any menus at all. All other menus would be nice to have in my opinion, but personally I would like to see at least "Quit" and "About XXX" menus. If we had default "About XXX" menu we could then also provide a default about window, with Oracle/JFX logo and links in there, which would help our brand. 12-01-2012 FYI: Running a simple Swing application on the Mac gives the standard menu (without 'Preferences') and uses the class name that contains main() for XXX. FYI: Running a simple FX application gives only the 'Quit XXX' and the application name is 'java'. I realize that this was discussed before and it was decided that the application name should come from the application bundle. 12-01-2012 This is the standard menu for pretty much every Mac desktop application: About XXX ---- Preferences��� Services -> ---- Hide XXX Hide Others Show All ---- Quit XXX Applications sometimes add application specific items after 'Preferences...'. A Mac application that does not have this menu structure looks out of place on the desktop. We can either model this in API or require that each FX application create this menu and install it when on a Mac. 12-01-2012 On the other events at some point we want to handle the sleeping/reopening of applications as part of the standard Application lifecycle as this will be common on many platforms such as mobile. 12-01-2012 I meant that using some naming convention and standard JavaFX Menus it would be possible for the application developer to create menu items in the application menu. Those items could be the standard "About ..." and "Preferences" but could also be other menu items. For example Safari adds other items to this menu. If we have this ability then I don't think there is a need to provide a standard About or Preferences menu item by the platform. 12-01-2012 Yes, it is possible for JFX devs to install their own "About" and "Preferences..." menu items, which would look exactly same as the ones we can automatically provide, so strictly speaking we don't need to install them automatically. Glass Application even makes the name of the app available, so the "About XXX" , where XXX is the name of the app as shown in Dock, can be absolutely implemented by developers themselves. 11-01-2012 Do you mean that JavaFX will create each of the standard items or that creating an 'Application' item will do something magic? 11-01-2012 Is there a way with our new Native menus so that we could create a menu in JavaFX with some name like "Application" and all the items in that menu will be added to the Applications menu on Mac? 11-01-2012 Glass in fact used to add About and Preferences menu item, in addition to Quit (which we still add), but I removed them as at the time we did not plan on having Application callbacks to make them useful. Now that we formally started the Application callbacks I indeed agree that a default Mac app should include both About and Preferences menu items and the associated callbacks, though JFX developers could easily add those by themselves now that we'll have menubar exposed in JFX. It should be easy enough to add those menu items back and provide the necessary callbacks if that's want we want. We should probably get Jasper's input here on whether we also want to provide a default "About" window, and if so what it should look like. 11-01-2012 To be well integrated on the desktop and not look out of place, a Mac application should implement "About XXX" and "Preferences...". From the Designer tool point of view, neither of these are needed unless the Designer tool is going to be stand alone. From what I understood, it is a NetBeans plugin. However, the title of this bug report is currently "Implement com.apple.eawt APIs that make sense in JFX." and "About XXX" and "Preferences..." make sense ... 11-01-2012 Double clicking on app's document will work now that RT-18118 has been fixed. The APIs in ApplicationListener according to the docs are: void handleAbout(ApplicationEvent event) Called when the user selects the About item in the application menu. void handleOpenApplication(ApplicationEvent event) Called when the application receives an Open Application event from the Finder or another application. void handleOpenFile(ApplicationEvent event) Called when the application receives an Open Document event from the Finder or another application. void handlePreferences(ApplicationEvent event) Called when the Preference item in the application menu is selected. void handlePrintFile(ApplicationEvent event) Called when the application is sent a request to print a particular file or files. void handleQuit(ApplicationEvent event) Called when the application is sent the Quit event. void handleReOpenApplication(ApplicationEvent event) Called when the application receives a Reopen Application event from the Finder or another application. The "handleAbout" , "handlePreferences" and "handlePrintFile" APIs are not needed because JFX app needs to implement its own menu items (aside from Quit on Mac). The "handleQuit" and "handleOpenFile" APIs are already implemented in Glass Application.EventHandler (which on Mac installs Quit menu item automatically) So we are left with the following APIs: void handleOpenApplication(ApplicationEvent event) Called when the application receives an Open Application event from the Finder or another application. void handleReOpenApplication(ApplicationEvent event) Called when the application receives a Reopen Application event from the Finder or another application. Those APIs allow another app to open and re-open our application in question. Those seem like a very low priority for now. In summary, Glass currently implements "openFiles" and "quit" Application callbacks, which sounds like from Designer Tool point of view is all that is needed at the moment. 11-01-2012 The API with more priority would be: - Application.addApplicationListener(ApplicationListener listener) - ApplicationListener.handleOpenFile 11-01-2012 We have an association between .fxml extension and the Scene Builder. When a user double click an FXML we want the running SB instance to be notified with the list of selected files to open. We need something similar (registration and event) as what is described in http://developer.apple.com/library/mac/documentation/Java/Reference/1.5.0/appledoc/api/index.html?com/apple/eawt/Application.html Making it a internal API for now is fine for SB. 11-01-2012 RT-18118 adds a callback for OpenFiles, when files are dropped onto app icon. 10-01-2012 Jean-Francois, which com.apple.eawt APIs is the DesignerTool currently requiring? 10-01-2012