Community
Participate
Working Groups
For the case that the plugin project name the icon file resides in differs from the plugin id, the icon is not found. The effect is that the launcher is not branded at all. This applies also to the 3.1 release. Though it is not that tragic for those who know how to work around it still should work.
This also applies to the icon bitmaps. Can pde.ui store the file locations in the .product file as /<featureId | pluginId>/path.to.the.file instead of as /<projectName>/path pde.build does not know about the workspace, and is currently interpreting that first segment of the path as the plugin/feature-id.
*** Bug 121630 has been marked as a duplicate of this bug. ***
this sounds more like a pde/build limitation/bug than a pde/ui bug. What's the deal here? at the UI level, we could restrict the browsing to plugin/feature projects, but does not solve the issue. PDE/UI is passing you absolute paths in the IXMLConstants.PROPERTY_LAUNCHER_ICONS ant property, so you can remain workspace-agnostic. Are you looking at these values we are passing you or are you looking at the product file yourself?
We are reading the product file ourselves. We use the PROPERTY_LAUNCHER_ICONS property if we don't have a product file. At script generation time, we don't know if that property will be set, which is why we go with the product file first. Perhaps we should use both, take what we understand from the product file, and add the property at the end of the list. And then be careful of duplicates at branding time.
Andrew, we just do that. That was my understanding from Jeff, when we dicussed this issue back in 3.1: "Using the UI, people should be able to put the icons wherever they want, since pde/ui is passing to pde/build absolute paths. If they want to take advantage of the headless pde/build for this, then the first segment must match the bundle id. So this is just an extra restriction for headless builds." We could make that clear in the documentation.
In 3.1 timeframe pde build was not able to completly export RCP apps standalone, so it might have make sense at that time. Now that pde build is able to completly export RCP apps, then having this liberty of putting icons anywhere just brings more problems than it solves. That's why I propose that we now always restrict icons to come from a plugin or a feature. This put an new restriction on people solely building their app of the IDE but make the life of people who build their app in a releng style much easier and they don't have to debug why the exe is not branded nor to read the fine lines.
re comment 6, I disagree. This plugin id == project name restriction as you export from the IDE is arbitrary and unnecessary. People dont' care that under the covers PDE/Build is being called and PDE/Build is workspace-agnostic. it is more important to them that they have their icons laid out wherever they want, and have the export wizard do the work. Now for people who want to use headless pde/build should play by pde/build's rules and comply with this restriction.
I personnaly think that any serious RCP development will build the product in a releng style, and having people to change their project structure is just an extra hassle.
Created attachment 35560 [details] patch The attached patch does the following: 1) The branding call in the ant script will now use both the ${launcherIcons} property (expected to be a comma separated list of paths) and the paths from the .product file. This fixes the problem in the case of export since pde.ui gives us the property. In the releng case, the user at least can set the property if his project name is not the same as the plugin-id/feature-id. 2) Changes to the IconExe to not completely fail on a bad image and to use the first matching image on the list. This means that images in the launcherIcons property will be used before images in the .product file if we have both.
Patch released in HEAD.
I have applied this patch and I see the following problems: - the product file is used prior to the property, that's why it still does not work if a product file is there - one must create the property manually, it should be copied if 'synchronize before exporting' is turned on
Oh sorry, I didn't see that you already commited the fix to the CVS. It does work. Thanks.
*** Bug 114994 has been marked as a duplicate of this bug. ***
