Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 316490

Summary:	The icon defined via windowImages is ignored on Mac/Helios
Product:	[Eclipse Project] PDE	Reporter:	Jan F. <jan>
Component:	UI	Assignee:	PDE-UI-Inbox <pde-ui-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	major
Priority:	P3	CC:	prakash
Version:	3.6
Target Milestone:	---
Hardware:	PC
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:	stalebug

Description Jan F.

2010-06-10 12:29:16 EDT

Build Identifier: 3.6.0.v20100513

If I define a set of icons to use in my RCP app via the windowImages property, they should replace the launcher icon once the app loads on Mac, so that the window icon is displayed in the Dock and app switcher.

I have spent total about 10 hours debugging this, always assuming this is a problem with my configuration, but after debugging through the platform code, I now believe this is a bug introduced by the new progress display over the icon.

Essentially, this is how I believe the icon lifecycle happens during startup:
- the launcher icon is displayed (from the icns file)
- the Progress reporting in org.eclipse.swt.widgets.TaskItem reports progress, it takes the icon currently in use, which somehow ends up with a low-res version of the launcher icon (via the call OS.objc_msgSend(this.id, OS.sel_applicationIconImage); in NSApplication.applicationIconImage() )
- the icon from windowImages is set, it stays as the app icon in the dock for some short period of time
- the icon is replaced with the earlier icon with a new progress

This is IMO a serious problem, as the low-res icon on Mac really makes a bad impression in terms of the (RCP) app quality, and also since this is a regression from Galileo.

Reproducible: Always

Steps to Reproduce:
1. Create RCP app on Mac using PDE
2. Define the app window icons (large res like 256x256) via the windowImages property
3. Launch the app

Watch the dock icon change from: launcher -> low res launcher -> proper icon -> low res launcher

Comment 1 Prakash Rangaraj

2010-06-10 12:45:56 EDT

What happens when you export and run that application? Does it works fine?

Comment 2 Prakash Rangaraj

2010-06-10 12:50:14 EDT

(In reply to comment #1)
> What happens when you export and run that application? Does it works fine?

    If it works fine, then this bug is a duplicate of Bug# 304778. Assigning to PDE to review this.

Comment 3 Jan F.

2010-06-10 12:57:57 EDT

It actually does behave a bit different:

- when I launch from PDE, the App ends up with a high-res default icon (paper
with ruler, pen and brush), instead of my icon

- when I launch the exported product, the App ends up with a low-res version of
the launcher icon

- when I launch the exported product without launcher icon (just removed the
icns from the product definition), the App also has the nice high-res default
icon

It seems that there are two problems:
- when I have icns file, the platform derives a lower res version of it (32x32
it seems) for the purpose of reporting progress
- the platform does not take into account that the app icon might be defined in
the windowImages property and the dock/window icon might change mid-startup as
a result of that

Comment 4 Jan F.

2010-06-22 10:17:34 EDT

Is there a workaround for this for now, such as turning off the progress bar on the dock icon?

Comment 5 Jan F.

2010-07-26 10:04:18 EDT

I have found a workaround for this (purely by coincidence), which also explains why Eclipse itself does not exhibit this problem.

In my Application class (implements org.eclipse.equinox.app.IApplication) I have copied some code from the Application class in org.eclipse.ui.ide.application to deal with Workspace switching. My app icon suddenly got fixed, and I narrowed the code down to those couple lines of code in the start () method:

// look and see if there's a splash shell we can parent off of
Shell shell = getSplashShell(display);
           
if (shell != null) {
   shell.setText(ChooseWorkspaceDialog.getWindowTitle());
   shell.setImages(Dialog.getDefaultImages());
}

the setImages apparently fixes this bug.

Comment 6 Eclipse Genie

2019-04-05 17:24:15 EDT

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.

Comment 7 Lars Vogel

2019-10-09 07:04:11 EDT

This bug was marked as stalebug a while ago. Marking as wontfix.

If this report is still relevant for the current release, please
reopen and remove the stalebug whiteboard tag.