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.me...@novell.com <><, Pseudo Engineer, itinerant idiot _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice