Community
Participate
Working Groups
Should be the name of the application. Eclipse RC2, File > Export... > Eclipse Product. Multi-platform.
Where does title come from?
I don't know. Probably should add somebody to the list who has experience with the platform customization for carbon.
CarbonUIEnhancer initializes the About and Preferences menu items in the application menu, but doesn't have anything to do with the menu title. Seems likely something is missing from the generated info.plist. Below is what is there already: <plist version="1.0"> <dict> <key>CFBundleExecutable</key> <string>XMLBuddy</string> <key>CFBundleIconFile</key> <string>xmlbuddy.icns</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>XMLBuddy</string> <key>CFBundlePackageType</key> <string>APPL</string> <key>CFBundleSignature</key> <string>????</string> <key>Eclipse</key> <array> <string>-startup</string> <string>../../../startup.jar</string> <string>-vmargs</string> <string>-XstartOnFirstThread</string> <string>-Xms30M</string> <string>-Xmx150M</string> <string>-Dorg.eclipse.swt.internal.carbon.smallFonts</string> <string>-Dorg.eclipse.swt.internal.carbon.noFocusRing</string> </array> <key>LSUIElement</key> <string>1</string> </dict> </plist>
It's not the info.plist. The Eclipse info.plist has nothing that would set the application name. It's in the generated startup.jar, which is apparently too generic. If you launch the startup.jar for Eclipse directly, the application name "Eclipse" appears immediately. If you launch the generated startup.jar directly, the application name "java" appears immediately. Added Andre to the list. Sorry, Andre. Gotta have someone who knows what the problem is. ;-}
In general the Info.plist key/value pair "CFBundleName" determines the name of the application menu. For SWT application this is true if the application is launched via the JavaApplicationStub (or java_swt) found in the Contents/MacOS directory within the application bundle. If the SWT application is launched via the Eclipse launcher "eclipse.exe" (which is true for Eclipse itself and RCP applications), setting CFBundleName has no effect. In this case the Display's setAppName method takes effect. For Eclipse it is called from Workbench.createDisplay(); for RCP apps I doubt whether it is called. Please note: you need to call Display.setAppName *before* the Display is created because the name is only used when initialising SWT's MacOS implementation. Calling it later has no effect.
Bob, so the workaound for you could be to call Display.setAppName early. However, this problem needs be fixed for RCP applications in general. (BTW: on MacOS /usr/bin/java takes a "-Xdock:name=<application name>" option which SWT does not yet support; I've filed bug #101839)
It's set by the product appName property on Windows, which is in the docs (not what it does, but it's there). The RCP examples I've looked at didn't use it and it didn't do anything on Windows so I didn't have it in my plugin.xml. 1. What the appName property does should be documented. The comments in the code around this property are misleading, to say the least - it apparently is used for one purpose on Motif and a completely different one on MacOS X. 2. appName should be set in all template-generated RCP apps, for the benefit of monkey-see, monkey-doers like me. I haven't checked them all but I know it's not set in the Mail app. It takes awhile to build for multiple platforms. I'll report later whether this is a fix for MacOS X.
Yes, setting the appName property in the product configuration file causes the name to appear as the title of the MacOS X application menu. Thanks for your help, Andre. I wouldn't have found it (maybe by accident, trying everything) if I hadn't known where in the code to look. Gotta file two more bug reports, though.
Hello, In Eclipse 3.2M4, specifying the "Product Name" in xxx.product under "Product Definition" (where it is written: Specify the name that appears in the title bar of the application) doesn't work. When I export my rcp application and launch it it is still the "java" menu that is appearing and not the name I entered.
Make sure that you clicked on the synchronize link on the first page of your product.
Thanks for your answer. Clicking the "sychronize" link doesn't change anything. I am using Mac OS X 10.4.4 Java 1.5 latest release from Apple. Does it work with you ?
I can confirm that it is an OS X problem only. On a windows XP machine, the menu is correctly displayed.
When I add the line Display.setAppName("my name"); as the first line of the run routine in the Application of an RCP, and run it within the IDE, then "my name" is properly displayed on the menu. When I export the RCP product, "java" is displayed instead. This is OSX 10.4.5 and Eclipse 3.1.2.
is this something that can/should be looked at for 3.2?
Note that this bug is in the UI component but assigned to PDE-build-inbox - If this is intended for UI I suggest reassigning to somebody sees it.
I would love seeing this solved for 3.2 final... someone on this ?
Moving to platform-ui for investigation. I think a patch would greatly help in this space because UI team has already come up with the list of things for RC2. Dominique, Philippe, or someone else on the cc list, could you look into a patch for that? It should be pretty straightforward.
Sorry, I think that you are overestimating my capabilities... However, I found this link: http://dev.eclipse.org/newslists/news.eclipse.platform.rcp/msg11909.html and http://dev.eclipse.org/newslists/news.eclipse.platform.rcp/msg11912.html I sent the guy an email, maybe he would be able to provide a patch...
Without a patch that is ready to go, I won't have time to look at this for 3.2.
PaScaL, since you are invoking my name, I'll see if I can have a look at it by the end of this week ;-) Please have zaroo expectations from that :-)
and if someone else wants to work on that, let's make sure we coordinate through this bug...
The export of RCP applications in Mac OS X follows more Windows-y type conventions than Mac ones. Using the JavaApplicationStub seems like (long-term) the right way to go for both Eclipse on Mac and also exported RCP applciations. I tried to put something together for an all-in-one bundle (see http://alblue.blogspot.com/2006/04/eclipsemac-maclipse-and-maclipse-lite.html and bug 57349). I also tried to get something working with the JavaApplicationStub and ditch the 'eclipse' launcher, but had some problems with the UI components now the UI is integrated with the startup splash screen ... I think the launcher is very much stuck in the world of how it would be launched on Linux in an IDE environment. An RCP Mac application doesn't need dynamically restartable/changeable workspaces, but it does need to be packaged inside a single .app file. Not sure I can provide a patch for this as requested in comment #18, but I've done some of the work towards what a repackaging will look like. (I've just moved house, so I've not got a lot of spare time for Eclipse stuff). I'll look and see if I can get a better launcher with the 3.2RC2 build in the near future.
An attempt at capturing the important details in one place... comment #13 says that 'Display.setAppName("my name");' isn't working in the exported RCP app -- Do we create the display before any client code is called? Is there a place in the RCP application startup where they can insert that code? That *should* be the only reason why it won't work. If the Display hasn't been created, but calling that doesn't work, it's an SWT bug. comment #8 says that setting the appName property in the product configuration file does work, but comment #11 says that it does not. Where (in the files making up the exported RCP app) does Dominique need to look to see that the appName property is set? comment #22 seems more long term to me. I'm happy to discuss better, mac specific, packaging/launching stories (really, I am!) but not when we're coming up on RC3. It's just too late in the cycle to be doing that. I would suggest moving that discussion to a new bug report and we can continue there.
Maybe it could be also usefull to see how it is done with Eclipse itself as it is correctly displaying with this application. I just don't know where to look...
(In reply to comment #23) > comment #13 says that 'Display.setAppName("my name");' isn't working in the > exported RCP app -- Do we create the display before any client code is called? > Is there a place in the RCP application startup where they can insert that > code? That *should* be the only reason why it won't work. If the Display hasn't > been created, but calling that doesn't work, it's an SWT bug. In a typical RCP application (e.g., the Mail example) the first line of the Application's run method calls PlatformUI.createDisplay(), which in effect calls Display.setAppName(Platform.getProduct().getName()). I have no idea why this works when you run the RCP application from Eclipse, but does not work in the exported product.
Perhaps we aren't looking in the right place for the product information?
Stepped through the code and in ProductProperties.java, method getAppName calls product.getProperty(APP_NAME) which returns null, instead of product.getName() which returns the expected application name
I haven't followed this deeply but in comment 27 you have to distinguish between apps and products. Products are extensions that identify apps and various branding elements. Apps are extensions that identify a class to run. something like getAppName() I would hope tries to get the app name from the product.
I just created a small rcp app (based on the mail template), exported it, ran it and the title of the app was corrctly indicating the name of my app (here I'm talking about the first menu in the menu bar). To me this everything is fine here. I will attach the plugin that I used to create this.
Created attachment 40992 [details] Plugin and product file used to confirm the proper behavior
I see same behavior as previously described. What version of Eclipse are you using?
I'm using eclipse RC3 + some pde build patch that will be in the I build from tomorrow morning. Could someone attach a reproductible test case?
Hello, I can confirm that the application menu is displaying correctly the name of the app when the application is exported to a mac RCP binary with Eclipse 3.2 RC4. The export was made on a mac with RCP-SDK RC4 and delta pack RC4 as a target. However, if you launch the application from within Eclipse, the application menu is still displaying "java" instead of the name of the app.... but actually I don't care as long as the exported app is displaying its menu correctly. Thanks for all the good work.
In the end it worked without change
I see this bug has been closed, but I don't think it has been fixed. When I export the Test RCPApp (attached to the bug) with the final 3.2 release (MacOS X 10.4.7, ppc) and launch the exported product (outside of eclipse) it still exhibits the problem. The application name is "java" in the menu bar and lists "Quit java" in the menu.
I think I've found the reason for the descrepency in verification. If I install the RCP 3.2 delta pack and then do the export, the application name shows up correctly. If I try to export the product without installing the delta pack, I get "java" for the application name. Perhaps this bug should be reopened?
Reopening and moving to Runtime. We call Platform.getProduct().getName() and then call SWT's Display.setAppName(), passing the result of the previous call. It seems to me that Platform.getProduct().getName() sometimes returns null when it shouldn't.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This bug has been marked as stalebug a while ago without any further interaction. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard flag.
