[Libreoffice] Icon/Image cleanup

[Michael Meeks]

Hi Joseph,

On Sat, 2010-11-06 at 03:56 -0700, Joseph Powers wrote:
> Ok, I went ahead and did some high-contrast cleanup work on libs-core.
> I was able to delete massive amounts of code and configuration items.
> The main issue I'm having is the masking:

	Just got back, and started reading your patches; this is some really
nice work :-) I love deleting huge gobs of mostly pointless code -
that's great fun.

> ImageList RID_DEFAULTIMAGELIST_SC
> {
>     Prefix = "sc";
>     MaskColor = STD_MASKCOLOR ;
>     DEFAULT_IDLIST
> };

..

> Please note that the MaskColor for high-contrast icons can be
> different then the one for standard icons. These may need adjusting.

	It is entirely likely that the MaskColor will only be used if the icons
are not alpha-transparent bitmaps :-) it might be worth looking at what
the DEFAULT_IDLIST is to see if any are.

	We may find that the "MaskColor" code is another total anachronism that
we can throw out, along with the other dinosaurs :-) no doubt there is
some place that it is used, but ...

	If we could verify that it is only used for non-alpha Bitmaps - then
(perhaps) we could simply check all of default_images for non-alpha
bitmaps, and isolate any remaining places more easily.

> The above gets compiled into a .res file; if anyone knows how & where
> it gets loaded back at runtime, could you share the secret please.

	Well - the res files are referred to by ID, so if you have:

ImageList RID_DEFAULTIMAGELIST_SC

	I -think- that there needs to be an RID_DEFAULTIMAGELIST_SC reference
in the code somewhere; unless this is some special case for ensuring
that res/commandimagelist/* ends up inside the .zip file [ AFAIR we
subset only mentioned icons - which perhaps we could stop doing too ]

> And some times they get fancy and load/cache both images:

	Shame; wastes time, and memory.

> 2. Determine how to handle the odd cases:
> a. We have code that detects changing from HC to Normal and back... Do
> we need this? Changing icon themes just work and HC is just at theme;
> thus, I don't see the need for this code.

	If icon theme change works correctly (and we should be updating on that
properly of course), then we don't need it. I suppose in the cases where
changing the contrast setting works it might be worth simply re-using
that code for theme change (if there is no equivalent code for that).

> b. We change colors on some controls based on HC mode. Wouldn't it be
> better to create a 2nd color scheme for HC. (calling all artist...
> please switch the icons to HC, and then change the colors until it
> looks good(actually bad-it needs to be HC which isn't pretty). We'll
> then need to figure out how to package the colors for shipping.

	Right ! we should have a single set of style colors; and simply use the
right colors from the color theme for high-contrast mode rendering. That
is important because it also enables the mirror impairment that requires
"low contrast".

> I haven't played with the icons/images yet. That'll take work trying
> to figure out the build system (any volunteers?) So far, I've removed
> references for the following items:

	Oh - great list; I'll try to put some time this week into prodding the
icon theme building code so we can start actually removing these from
the default_images directly, and move them into a separate high-contrast
theme one by one as we remove the need for them.

> So far I haven't notices any additional break-age from these changes.
> The HC them has a few icons that disappear under Mac OS and changing
> the OS to HC just makes things worse; however, these are broken on the
> default build also... so no damage done.

	:-)

	Great work,

	Thanks,

		Michael.

-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot