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