Re: [Libreoffice] Icons

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@novell.com  <><, Pseudo Engineer, itinerant idiot