Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Description
mmeeks
2004-10-14 16:32:58 UTC
Created attachment 18401 [details]
a patch
kai, could you please evaluate this patch ? Michael, I applied the patch to one of my test CWS'S and was then showing the results to the lead of our Inhouse UserExperience group. Result was that he was not convinced at all to integrate this patch. Major issue was that in some/many cases the difference between enabled and disabled items was very small. This needs some more investigation to find the optimal thresholds, I think. I suggest to keep this patch for OOo later. Ka - thanks for doing that; I was about to flame your UI dept. but - it turns out, on comparing this with the Gnome result - it looks far worse. Just a simple problem - I was 1/2ing the Alpha on the insensitive icons; binning that code path ( an incremental patch of ): --- ../../ooo-build/build/src680-m62/vcl/source/gdi/impimage.cxx 2004-11-17 04:24:54.000000000 +0530 +++ source/gdi/impimage.cxx 2004-11-26 09:17:50.398984472 +0530 @@ -690,6 +690,9 @@ } } +#if 1 + aAlpha = maBmpEx.GetAlpha(); +#else BitmapReadAccess *pAlpha = maBmpEx.GetAlpha().AcquireReadAccess(); BitmapWriteAccess *pDisAlpha = aAlpha.AcquireWriteAccess(); if( pAlpha && pDisAlpha ) @@ -706,6 +709,7 @@ } aAlpha.ReleaseAccess( pDisAlpha ); maBmpEx.GetAlpha().ReleaseAccess( pAlpha ); +#endif } else { Gives a large improvement - such that it closely mirrors the Gnome effect (which is generally considered to be quite good I think ). I attach an image showing the before (above) and after (below) effect of this. Created attachment 19718 [details]
the 2nd change
Kai - any further advance here ? I attach the full re-worked patch in case it's at all helpful. Created attachment 20506 [details]
darkened / fixed patch.
I'm sorry, but I didn't find the time yet to evaluate the new patch. I just took a quick look and saw that it might need some minor corrections, although it already seems to work in general from a technical perspective. The guys from user experience area still need to give their input on this, too, of course. I will get in contact with them as soon as I have a patched office version available. A new version minus WriteAccess / ReadAccess leaks Created attachment 27193 [details]
latest version
So - any movement here - I just used an up-stream vcl cws to poke at some a11y work and was staggered by how ugly the insensitive icons were :-( Lutz, I'm re-assigning this to you & re-targetting to OO.o 2.0.3, I hope that's ok. This has been blocked for 7 months on "the guys from user experience" - that is not an ideal situation. When I talked to you about this & showed you the results the conversation was sadly inconclusively: AFAIR we wandered off into the issue of whether we should use this on Win32 too [ IMHO transparently, obviously yes - but I'm prepared to sacrifice the attractiveness of your Win32 version to get something decent on Unix & keep a patch in our tree to turn this on unconditionally ]. *Surely* it is not controversial to use *the same* algorithm for insensitization (rendering disabled icons differently) as the rest of the GNOME desktop. Of course - we can make the patch conditional to just GNOME fairly trivially. How is the process failure here going to get fixed ? preferably without a huge burden of building, hand-holding install etc. of 'stock' OO.o packages for the UI team - just so they can look at a few icons ? [ which we can trivially take screenshots of them for ]. This is a *really* non-controversial change: again - to make OO.o do the same thing as the rest of the desktop. It should be covered by whatever 'non-controversial' clause anyone has. It should be covered by the (still non-existent?) UI team guidelines as to what is non-controversial & does not require a lengthy wait. Hopefully this is a transient abberation that will be fixed by a more pro-active approach from the UI team ;-) I support applying this patch on the basis of consistency, especially if it emulates the GTK+ code in HighContrast and HighContrastInverse themes. (Michael, you may wish to check the HighContrast gtk-engire for this). The biggest accessibility issue with visibility of the "disabled" components has arised in the HighContrast themes. If this patch works equivalently to the HighContrast gtk+ engine and looks consistent with the base gtk+ engine, I think it should be applied (at least when using the gtk+ look). Michael, I do not want to block this issue. In order to make a fast but well educated decision, I need to have a better picture of the result in comparison to what OOo looks like today. I am trying to get some examples from our Sun developers, but whatever you can provide helps me to speed up my decision. In detail I need screen shots from full Writer windows (incl. window decoration) at a size of approx. 1,024 x 400-something, so that the full standard toolbars are visible. Here are the scenarios I need to or I'd like to look at: 1. Must see: - Windows XP (Luna Theme) with and without patch - Windows XP (High Contrast Theme) with and without patch - JDS 3 (Default Theme) with and without patch - JDS 3 (High Contrast Theme) with and without patch 2. Like to see: - Windows XP (Classic Theme) with and without patch - Gnome (Default Theme) with and without patch - Gnome (High Contrast Theme) with and without patch 3. Optional see (would be nice to see, but these are really optional): - Windows Vista February build (Default Theme) with and without patch - KDE, recent release (Default Theme) with and without patch - KDE, recent release (High Contrast Theme) with and without patch Sounds like a lot? It in fact is, but as Bill's comment already indicates, there is quite some context to look at in this case. And it certainly is less expensive to look at all these cases upfront, rather than discovering insufficiencies later (or even letting our users discover them). Thanks Bill; wrt to: > especially if it emulates the GTK+ code in HighContrast and > HighContrastInverse themes. Yes of course; the same algorithm is in fact used there (AFAICS) from gnome-themes/ - it's quite versatile; cf. gtkstyle.c (gtk_default_render_icon)'s call of gdk_pixbuf_saturate_and_pixelate. > (Michael, you may wish to check the HighContrast gtk-engire for this). Sure - tested, behaves as expected from above. Of course, OO.o cannot use the gtk+ theme icons itself, since there are just not enough by an order of magnitude but ... > If this patch works equivalently to the HighContrast gtk+ engine and looks > consistent with the base gtk+ engine, I think it should be applied (at least > when using the gtk+ look). Great - thanks :-) Lutz: I can't provide the JDS3 stuff - but I can certainly get a few shots taken with the patch: presumably 'without' is easy enough for you to generate ? :-) Created attachment 35095 [details]
gnome - industrial 'old-style'
Created attachment 35096 [details]
gnome - industrial 'new-style'
Created attachment 35097 [details]
gnome - default theme 'old-style'
Created attachment 35098 [details]
gnome - default theme 'new-style'
Created attachment 35099 [details]
gnome - high contrast 'old-style'
Created attachment 35100 [details]
gnome - high contrast 'new-style'
So - I attach the images. Perhaps the most interesting contrasts are: industrial old vs. new - this shows what happens with the old algorithm when you have more than a 1bit alpha channel: the images get horribly blured. Of course the new algorithm retains some color - so, you get a better albeit de-saturated & pixelated image too. I think this is the limit of what we can achieve for you here (easily) - I've asked Tor to add some Win32 shots: should be there in a sec. Created attachment 35101 [details]
Windows XP - Windows XP Theme, Default color scheme
Created attachment 35102 [details]
Windows XP - Classic Theme, Windows Standard color scheme
Created attachment 35103 [details]
Windows XP - Classic Theme, High Contrast White color scheme
Michael and Tor. Thanks for the screen shots. Looking at them, I strongly object against integrating the patch. I agree that the "disabled" icons (insenitized, as you call them) can better be recognized with your patch applied. But they don't distinguish well enough vs. "enabled" (sensitized?) icons any more. I showed the screen shots to two graphic designers - in a neutral fashion - and both immediately rejected the new design. The benefit of the old solution is, that the contrast between a disabled icon and the icon background is very low. So without even looking at a particular icon, users automatically "avoid" them by focussing on enabled icons only, which are marked by a clear contrast ratio between icon and background. The down side of your current solution becomes most obvious, the fewer colors an icon uses. There are plenty of black&white icons in OOo's default theme, and in High Contrast mode even more. With your patch applied, these can no longer easyly be distinguised from enabled icons. Instead of just overlaying the icon with an "every second pixel gray" layer, the entire icon needs to be desaturized some way. Maybe it would be worth a try to go into this direction instead of your current approach? They prefer gnome-industrial-old.png to gnome-industrial-new.png ? that is incredible to me - Let me ask my artists to weigh in. Ultimately the gross insensitisation there that is what we are facing & the root of our problem; we care not at all for the 'default' icon set, none of our users see that. I cannot have our desktop look like this: http://www.openoffice.org/nonav/issues/showattachment.cgi/35095/gnome-industrial-old.png it has to look like this :-) http://www.openoffice.org/nonav/issues/showattachment.cgi/35095/gnome-industrial-old.png As a solution we can add more code that flags an icon set as being 'old' / non-deep-alpha / few-colors / palletized and uses the old code for that - would that satisfy you ? or are your expert graphic designers [ presumably the same people that came up with the existing 'default' icon set ] opposed to that too. Similarly - from an a11y point of view - inexperienced as I am I have to say that eg. the bullet indent/de-indent icons at: http://www.openoffice.org/nonav/issues/showattachment.cgi/35099/gnome-hc-old.png are almost invisible to someone with good low-contrast vision, and almost certainly entirely so to someone with poor contrast perception. Compare it with: http://www.openoffice.org/nonav/issues/showattachment.cgi/35100/gnome-hc-new.png and perhaps you have the opposite problem: but at least you can see *something* [ the opposite being mainly a function of the artwork's use of color/alpha etc. ]. So - again; I want to get my patch up-stream; it should not be controversial to make it behave in the same way as the rest of the platform; would you have a problem with making this apply for everything except your 'default' theme. I think - *perhaps* it is unhelpful that the shots are not all taken with the toolbar in the same state - eg. the control palette is 'in design mode' in the HC 'new' shot and not in the old one; sigh. To me the patched version looks very nice; although i might add that the idea of desaturation to complete greyscales has some appeal. But on the other hand that desaturation would completely fail for icons that are more or less black and white already; and we have quite a few of them if you look at the toolbar. For the same reason this would not go well with highcontrast icons in general since they tend to be black and white already. Basically there will probably not be a strategy that works for every conceivable case; the design of the icons has to take account of the method that will be applied to display disabled icons. Just my 2 cents. Thanks Philip. When I say "it has to look like this :-)" (2 comments above) I mean this: http://www.openoffice.org/nonav/issues/showattachment.cgi/35095/gnome-industrial-new.png My problem is that in searching for the perfect solution to all potential problems with any improvement that we end up sticking with something that is clearly shocking for way longer than necessary. Hi Michael. Are you sure that the most recent screen shot really is what you wanted to post? http://www.openoffice.org/nonav/issues/showattachment.cgi/35095/gnome-industrial-new.png still looks exactly the same as ...-old.png on my system... To re-iterate on my comments: I admit that the current method of visualizing disabled icons makes some/many icons no longer recognizable. OK, they are disabled anyway, so why would anyone want to recognize them anyway? Assuming that there is a valid need to do so, we need to find a better way to "fade" these icons. The requitrements so far are: - a disabled icon must be clearly distinguishable from an enabled one - a disabled icon must still be recognizable, i.e. users need to be able to identify the sunbject of the icon image These requirements seem to be contradictuous per se, but looking at current desktops like Windows and Gnome proves that it is possible to satisfay them both at once. Judging from http://www.openoffice.org/nonav/issues/showattachment.cgi/19718/old-to-new.png, there seems to be at least one solution that is far mor effective than the one depicted in all the Writer screenshots. Would it be helpful to focus our discussion on measurable aspects, like "the contrast ratio must not be lower than x:y" or similar? Lutz: you're quite right - turns out the file name is irrelevant in this just the number; try: http://www.openoffice.org/nonav/issues/showattachment.cgi/35096/gnome-industrial-new.png vs. http://www.openoffice.org/nonav/issues/showattachment.cgi/35095/gnome-industrial-old.png The number in the URI being (apparently) the critical bit ;-) and (URGH) - looking at this more closely, it looks as if the algorithm is in fact slightly different; or there is some offsetting prolem that degrades the look of (at least) 1 icon in OO.o I've checked: investigating that. Either that or we're still not using the fix in comment 5 (yet). Examining the algorithm in more detail - I notice we're missing part of the de-sat. algorithm; but - adding that has only a small effect - nevertheless will re-generate some more images. Worse - in showing that the pixel values are in fact identical between the two - it becomes rapidly apparent that the OO.o PNG load code is rather broken - it loads darker PNGs than in fact are on the disk. At least if you load / display eg. 'lc_undo.png' it displays rather differently [ with nothing clever / no-insensitisation ] in OO.o than in gedit / the gimp / etc. I would guess that this is related to the decision not to use libpng in OO.o's iamge loader [ no idea why that is the case ]. I attach an improved patch that tweaks the algo. a bit more to be 100% GNOME compatible ;-) of course, this is still hard to tell because of bug i#63485# but you get the general idea. I also attach a new set of 'GNOME' shots - these are rather similar to the intial set, but (perhaps) the contrast is better for HC & default; not sure. Created attachment 35123 [details]
gnome industrial new (updated)
Created attachment 35124 [details]
gnome default new (updated)
Created attachment 35125 [details]
gnome high contrast new (updated)
Created attachment 35126 [details]
last word patch (?)
Created attachment 35131 [details]
photo of gedit vs. OO.o insensitisation
added KA to Cc list a week passes responselessly ... ;-) Spent several weeks of inactivity on this one. Sorry for that. Getting back to this issue ater some time really is hard because of the many iterations. I wish we could work this out in a more straightforward manner. Can we agree on attaching screen shotsfrom the entire toolbar area only? I still support the general goal of improving the display of insensitized icons, ideally by complying with UI guidelines of the respective desktop. And I still insist on matching the requirement to be able to easily distinguish insensitized icons from sensitized ones. So how can we move forward with this? Let's set the target to a more realistic one, as it seems that there are still some tweaks necessary. 2.0.4 seems pretty realistic. Further, I would like to have a solution not only for one special case (icon theme X on desktop Y), but a more general one that applies to all supported desktops and works well with all major icon themes. So what is the exact status on the patch? Judging from the latest complete screen shots we haven't quite achieved a good distinguishability between insensitized and sensizized icons, right? What can I do to make this issue move forward? lho - so, apparently (it seems) there is a yet-newer insensitisation algorithm used in clearlooks & newer derivatives [ most modern themes ] that does more de-saturization and no pixellation (or something). I mean to get to look into that at some stage when I have the luxury of spending time on this up-streaming process again. I see target is set for 2.0.4(?) Michael, not sure if my opinion holds any weight but I think your change makes it harder to see the disabled icons. Current approach looks much clearer. Regards, Andrew move target to next version because of code freeze. move target to later version because of code freeze. It looks the patch can't applied as is and needs some further work. Micheal, let us know, when you find the time to work on this enhancement. Changing issue type accordingly. /me as a user surely would not appreciate the change in its current form either. looking at gnome-industrial-new2.png I cannot tell what is activated and deactivated (apart from the list/comboboxes. My gnome themes never had such a little difference between active/disabled icons either. I agree that some of the disabled icons look very ugly when using the big theme (notably the cut, undo and redo ones), but I never liked wasting so much screen-space for buttons, so I'm using the small ones anyway (and with that the disabled ones look /much/ better compared to the big theme). So instead of trying to mess with the color-themes, make the shapes not suck in large icon theme instead - my 0,02€... mmeeks: after applying this patch I get some "pinky" icons in Industrial theme (see attached screen shot). I hope it is a bug in PNG images. Created attachment 43833 [details]
pinky icons
Can someone please update the patch to apply to src680_m217 ? thanks in advance. The latest patch will be included in ooo-build as/when we pull-up to m217 (works fine on m216 now): http://svn.gnome.org/viewcvs/ooo-build/trunk/patches/src680/ @mmeeks: fyi - just got this 80705 issue. Reset assigne to the default "issues@openoffice.apache.org". |