[Libreoffice] Icons

[Michael Meeks]

Hi Joseph,

On Mon, 2010-11-01 at 21:15 -0700, Joseph Powers wrote:
> I'm a little crazy, but I want to work on the icon issues.

	Cool - there is a rich seam of wasted run-time memory, startup-time,
and worse bloat in the Win32 packages here, all of which can be easily
fixed I think :-)

> I'm a programmer, so I've been looking at things from the
> other side...

	Great news; perhaps good to put your name in the Easy Hacks as working
on this task.

> Currently the system is a mess, the top level determines if
> if we're in high-contrast mode or not and then requests the
> correct image. On top of this, we have both themed and
> un-themed icons; thus, I can't just kill the high-contrast checks.

	Right - so - there is an easy hack for this:

http://wiki.documentfoundation.org/Development/Easy_Hacks#un-screw-up_accessible_icon_code-paths_.26_shrink_theme_files

	We need to totally remove all references to 'BmpColorMode' that are
used for selecting accessible vs. non-accessible icons - it is a total
joke of an attempt at accessibility :-)

	Similarly - we should chase all -icon- code down that has special cases
for high-contrast and remove it. Whomever implemented a11y had
(apparently) no idea that there is are also -low-contrast- impairments
as well as high-contrast ones :-) and the mechanism is fundamentally
inextensible, as well as made obsolete by high-level theming.

> From your earlier e-mails, you've said that each theme has both
> standard icons and high-contrast icons; this has to change. However,
> I'm stuck trying to figure out how the code knows which icon file
> it's requesting. The un-themed icons in chart2 are easy to tack
> since I found the mapping files; however, I'm having issues
> with the themed icons.

	Well; there are lots of hacks through the code:

svtools/source/contnr/templwin.cxx:        bLarge ? bHiContrast ?
IMG_SVT_DOCTEMPL_HC_BACK_LARGE : IMG_SVT_DOCTEMPLATE_BACK_LARGE

	The switch as to whether to do this is often fetched from:

sal_Bool bHiContrast =
GetSettings().GetStyleSettings().GetHighContrastMode();

	Almost every instance of this call is a bug ;-) if it is for an icon -
then it should be done using theming; if it is for a color - it should
be done by building different style themes in vcl and using generic
methods to fetch colors.

> I believe all the themes should be located the /artwork directory and
> we'll need to create a system for building/packaging them for
> inclusion into the project. We'll also need to determine a directory
> to house the installed themes. The current system of themes being hard
> coded into the build system needs to change; the users should be able
> to just drop a theme package and have the them auto-reconized on the
> change theme dialog.

	Yep - sounds great :-)

	Currently our hicontrast theme is built by packimages/pack/makefile.mk:

# generate the HiContrast icon set
$(MISC)$/hicontrast.flag .PHONY :
    $(PERL) $(SOLARENV)$/bin$/hicontrast-to-theme.pl
$(SOLARSRC)$/default_images $(MISC)$/hicontrast && $(TOUCH) $@

	Which runs a script that build that theme.

	Of course - that theme has the worst of all worlds: exact duplicates of
each icon twice - once as plain, once as hi contrast.

> I'm open to suggestions from any of the other developers.

	So ! :-) I suggest that we start by using the above perl script to
create an entirely new theme (in artwork/) "hicontrast" - that is
essentially the results of hicontrast-to-theme.pl - with all of the 'h'
variants removed from it.

	I suggest we then remove the 'h' variants from default-images
incrementally - as we remove their usage. So - we audit the
GetHighContrastMode calls to find the one that will switch all the
toolbar icons from lc_foo.png to lch_foo.png [ this will be in the
'framework' module and dependents ]. Then we remove all of that cruft;
in the code, and simultaeously remove res/commandimagelist/lch_*  and
sch_* from default_images/

	Then we iterate, incrementally removing more cruft left & right, until
we substantially shrink the size of images.zip :-)

> As far as I can determine the biggest savings would be to do the changes in this order:
> 
> 1. Remove the High-Contrast check from the themed icons.
> 	a) This should cut the themes in about half.
> 	b) Reduce a lot of code over head.

	Right :-)

> 2. Move the un-themed icons in to the default themes. 
> 	a) This only removes some redundant code paths for retrieving icons.
> 	b) Removes the last of the High-Contrast checks.
> 	c) Will need to verify that the missing icon fall-back code actually works.

	Sounds fine; I don't know how many un-themed images we have left; I
suspect few enough.

> 3. Make themes discoverable.
> 	a) No real savings, it's mostly a coolness factor. Plus it gives
>            the graphics designers something to do so they leave the
>            programmers alone.

	Sounds cool :-) One thing I think you missed was:

	* Encourage others to get involved with easy hacks ;-)
		+ one of these is renaming res/commandimagelist/... to
		  something in the top-level; say 'act/' - this would
		  save a bucket of space since these strings are
		  duplicated twice per image, per theme
		+ small code hack, with a nice, measureable win.

	But - sure - there is a deep vein of badness here to fix, with some
nice performance & memory side-effects.

	Wonderful to have you work on it ! be great to split the big task I
describe above into some more easy-hacks as/when you understand it, to
make the task incremental and get more people around it.

	All the best,

		Michael.

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