michael.meeks at novell.com
Tue Nov 2 03:21:49 PDT 2010
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:
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 =
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 :
$(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.
> 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.meeks at novell.com <><, Pseudo Engineer, itinerant idiot
More information about the LibreOffice