214174 - Create new icon module within the tree to centralize and remove hardcoding

Status: RESOLVED WONTFIX

(SeaMonkey :: UI Design, enhancement)

Description

[Brian 'netdragon' Bober]

The icons are a mess, and implementing a bug like bug 99380 will just make
things worse. All icons should be placed within a new module (icon subdirectory)
in the tree.

Within Firebird/Thunderbird:

It could be organised so that its sorted by the various applications that use
the GRE (firebird, thunderbird) 

icons/
icons/firebird/icons.mn
icons/firebird/firebird.rc
icons/firebird/program/firebird1.ico
icons/firebird/program/firebird2.ico
icons/firebird/misc/historyWindow.ico
icons/firebird/misc/bookmarksWindow.ico
icons/thunderbird/icons.mn
icons/thunderbird/thunderbird.rc
icons/thunderbird/program/thunderbird1.ico
icons/thunderbird/program/thunderbird2.ico
icons/thunderbird/program/thunderbird3.ico
icons/thunderbird/misc/composeWindow.ico
icons/shared.rc
icons/icons.mn
icons/shared/sharedWindow.ico
icons/shared/associations/XUL.ico
icons/shared/associations/Image.ico
icons/shared/associations/associations.txt

As you can see, the shared icons would be within icons/shared and association
icons would be in icons/shared/associations. An icons.mn (or something like
that) would contain the linking between icons and their resource names for
different operating systems. associations.txt would contain a listing of the
associations using the cross-platform name within the .mn file like this:

defaultIcon *
imageIcon jpg png gif
docIcon html htm
xulIcon xul
rdfIcon rdf
jsIcon js

On Windows, the program icons would be put into an executable while the other
icons could be placed within DLL files within their respective distribution
directories, such as c:/program files/mozilla.org/firebird/icons.dll and the GRE
would contain the shared icons.

For XPFE:

The same would be true, but all the icons would be placed in one DLL since there
are no separate distribution directories.


This icon module would be linked before any of the executables are linked.
Although I only touched on the Windows issue, it should also allow for icons on
all operating systems to be handled within the same module. For Linux, the icons
could all be placed within a distribution directory to be used by the window
manager.

This would probably fix bug 199576 and should also be implemented in my opinion
before bug 99380

It would also be nice if there were a new icon component that would be run by
someone who would know how the icon module implementation works and could
enforce a set of standards for how the icons should look and what res/color
depth they are along with how they work on all platforms. That way the regular
XP Apps developers wouldn't have to deal with icon issues as much.

Comment 1

[Brian 'netdragon' Bober]

For an example of how icons are a mess, the icons are hardcoded to the window
names. For example, see:
http://lxr.mozilla.org/seamonkey/search?string=main%5C-window&regexp=on

This is talked about in bug 199576 that I mentioned earlier.

Comment 2

[Brian 'netdragon' Bober]

The file that maps icon associations we could simply allow the last icon listed
for an association override all others. This has been discussed in bug 99380.

It'd be like this:

Define Group Images: *.jpg *.gif *.png *.tiff *.bmp *.ico
Define Group HTML: *.html *.htm
Define Group WindowImages *.bmp *.ico

*.* default.ico
Group Images image.ico
Group HTML document.ico
*.tiff tiff.ico

What would happen here is that first default.ico would handle every extension,
then image.ico would be named for all images within the previously defined group
which overrides image.ico then tiff.ico would be named for tiff, which overrides
image.ico. Since XML wasn't defined, it would use the default.ico

Notice .bmp and .ico were redefined in another group (WindowsImages). That means
that they would not be considered any longer as part of group Images, and
therefore would also have the default.ico since WindowsImages wasn't given its
own icon.

That would be if we only dealt with Windows. For the sake of cross-platform we
probably shouldn't use the actual icon names but provide an alias for each
operating system in an alias.txt file or something. Doing that, the module be
broken up based on operating system, and there would be a layer between the
names on different operating systems and the generic name used by the icon by
the cross-platform code.

In the interest of having the module responsible for its own packaging, we
should probably provide scripts within the module which would package these for
xpinstall.

Comment 3

[Brian 'netdragon' Bober]

I also didn't mention that using aliases for associations would also allow you
to create a directory structure for the locations of the association icons to
organize them in a meaningful way without having to reflect that in the file
that maps associations -- i.e. associations.txt

Comment 4

[Brian 'netdragon' Bober]

I am CCing ssu and dveditz because this would affect packaging.

Comment 5

[Brian 'netdragon' Bober]

I think this should wait until the associated file type icons are checked in.
That will give us a better idea of what we are dealing with.

Comment 6

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Is this still relevant?

Comment 7

[Serge Gautherie (:sgautherie)]

Filter "spam" on "guifeatures-nobody-20080610".

Comment 8

[Philip Chee]

> Is this still relevant?
Probably not.