429344 - McCoy has no application icon

Status: RESOLVED FIXED

(Other Applications Graveyard :: McCoy, defect)

Description

[Dave Townsend [:mossop]]

Since we use the xulrunner stub exe for mccoy.exe it only has a generic icon. Once opened the window icon is fine but shortcuts look ugly.

Comment 1

[Dave Townsend [:mossop]]

Attachment: patch rev 1

There are a few options here. One is to compile our own stub, but I'd prefer to avoid doing that. The other is to use a resource editor tool to add in the icon to the stub. Some are available, but it turns out to be pretty simple to create one that can be distributed with the McCoy source so here it is.

The tool is quite simple right now, it will just add a main application icon from an ico file. In the future it might be good to also allow changing the version resource which currently talks about xulrunner etc.

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

I'm reviewing. Looks good, but I just want to see if it's safe for using malloc/free with the WIN API functions or if GlobalAlloc/Lock are needed instead.

I also remember having problems with some hicolor ICON resources, so I want to check that. Lastly, Windows Explorer (shell) grabs ICONs differently than shortcuts on the desktop. Something about the ICON index in the resource. Looks like your code is ok as it seem to update all ICONs.

Comment 3

[Dave Townsend [:mossop]]

The code seems to bring in hicolor icons, I'm testing with the mccoy icon in tree which has both 256 colour and 32-bit colour versions. However the index might not be right. The example I was cribbing from suggested calling it MAINICON, but firefox.exe just seems to have 0 (app icon) 1 (document icon) and 32512 (app icon again?).

Comment 4

[Dave Townsend [:mossop]]

A note from an msdn article:

If an .EXE or .DLL file has only one RT_GROUP_ICON resource, the first step is trivial; Windows simply uses that resource. However, if more than one such group resource exists in the file, Windows must decide which one to use. Windows NT simply chooses the first resource listed in the application's RC script. On the other hand, Windows 95's algorithm is to choose the alphabetically first named group icon if one exists. If one such group resource does not exist, Windows chooses the icon with the numerically lowest identifier. So, to be sure that a particular icon is used for an application, the developer should insure that both of the following criteria are met:

   1. The icon is placed before all other icons in the RC file.
   2. If the icon is named, its name is alphabetically before any other named icon, otherwise its resource identifier is numerically smaller than any other icon.

Since there is no rc script here I'm unsure exactly how the order would be determined. But since the stub has no existing RT_GROUP_ICON, this can just work for now.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

Yep, that was one of the issues I was talking about. There is no RC script here, but there was an RC script with the stub when it was made, and I believe the replaced ICONs are in the same group as the original ICONs.

Since, as you state, there is no RT_GROUP_ICON, we shouldn't have a problem.

Comment 6

[Dave Townsend [:mossop]]

Sending        Makefile.in
Sending        app/Makefile.in
Sending        installer/Makefile.in
Sending        makefiles.sh
Adding         tools
Adding         tools/Makefile.in
Adding         tools/redit
Adding         tools/redit/Makefile.in
Adding         tools/redit/redit.cpp
Transmitting file data .......
Committed revision 12364.