Requirements for image loading:
	1. Pretty & distinctive OO icons
	2. Integration with Gtk icon theme (optional)
	3. AA icons / png loading (optional)
	4. stop icons linking with [L]GPL code (optional).
Importantly we mustn't sacrifice noticable performance for 2,3,4.

Loader details:
---------------

The main loading code is in vcl/source/gdi/bitmap2.cxx, starting at
::Read() in line 163.

The interesting function is ::ImplReadDIBBits at line 452.  Note how
it does not handle 32-bit BMPs (line 638), as it ignores the alpha and
just sticks in the RGB values.

Modifications for 32-bit support:
---------------------------------

* vcl/inc/salbtype.hxx: Added a BitmapColor constructor that takes in
  an alpha value, and modified the other constructors to set the alpha
  to fully opaque.  Added setters/getters for the alpha value.

* vcl/source/gdi/bitmap2.cxx: Make ImplReadDIB() handle up to 32-bit
  nBitCount.  Make ImplWriteDIBBits() handle 32-bit depths.

* vcl/unx/source/gdi/salbmp.cxx: Make ImplCreateDIB() handle 32-bit
  nBitCount.  Make GetBitCount() handle 32-bit depths.

* vcl/source/gdi/impbmp.cxx: Make ImplGetBitCount() handle 32-bit
  depths.

* vcl/source/gdi/bmpacc2.cxx: Handle alpha in the 32-bit
  getpixel/setpixel functions.

* vcl/inc/bitmap.hxx: Added BMP_CONVERSION_32BIT to enum
  BmpConversion.  It seems they don't know that in C/C++ enums start
  at zero and thus you can avoid explicitly numbering them...

* vcl/source/gdi/bitmap3.cxx: Make Convert() handle BMP_CONVERSION_32BIT.

* vcl/source/gdi/outdev2.cxx: ImplDrawBitmapEx() - Do compositing if
  the bitmap is 32 bits deep.

* svtools/bmpmaker/bmpcore.cxx: Make ImplCreate() ensure that
  everything gets expanded to 32-bit RGBA.

----------------------------------------------------------------------------------

This file contains notes about the BMP loader and the code path that goes from
grokking .bmp icon files to painting them on the screen.

- Icons are resources, each identified by a unique number.

- Icon files with an "lc" prefix are large icons, and the
  corresponding small version has an "sc" prefix.

- Icon files are called {sc,lc}XXXXX.bmp, where XXXXX is the numerical UID.

sfx2/source/toolbox/tbxmgr.cxx:359:
	USHORT nId = SID_NEWDOC; -- this is the ID of the icon

	pBox->SetItemImage(nId, pBindings->GetImageManager()->GetImage(nId, pIFace ? pIFace->GetModule() : 0));
		see sfx2/source/toolbox/imgmgr.cxx below

sfx2/source/toolbox/imgmgr.cxx:784: SfxImageManager_Impl::GetImage()
	::GetImage() implementation.  Builds "ImageList *pList" via SfxModule::GetImageList_Impl().
	Then calls pList->GetImage (nId)

sfx2/source/appl/module.cxx:120: SfxModule::GetImageList()
	Implementation of SfxModule::GetImageList().  Note the use of
		bBig ? RID_DEFAULTIMAGELIST_LC : RID_DEFAULTIMAGELIST_SC
	to decide between big or small images ("lc" and "sc" prefixes
	from above).

	tools/source/rc/resmgr.cxx:848:
		Calls LocalResource(), which is implemented in line 691.  This
		returns a pointer to a resource header, which in turn gives
		you the offsets to the actual resource data within the
		resource blob.

	Then it calls "new ImageList (aResId)".

vcl/source/gdi/image.cxx:749: ImageList::ImageList (const ResId &rResId)
	Note line 771, where it constructs a Bitmap from the resource ID.

vcl/source/gdi/bitmap.cxx:107: Bitmap::Bitmap (const ResId &rResId):
	Creates an SvStream and then uses an extractor operator (">>")
	to feed it into the Bitmap.  Joy.  How did we ever live before C++?

vcl/source/gdi/bitmap2.cxx:163: Bitmap::Read (SvStream &rIStm, BOOL bFileHeader):
	This is the BMP loader.  But it doesn't tell us where to find
	the resource data.  Hmmm.