Issue 35555

Summary: Insensitive toolbar icons ...
Product: gsl Reporter: mmeeks <mmeeks>
Component: codeAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: ace_dent, ht990332, issues, lohmaier, lutz.hoeger, ooo, rail_ooo, stefan.taxhet, tml
Version: 680m55   
Target Milestone: AOO PleaseHelp   
Hardware: Other   
OS: Linux, all   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
a patch
none
the 2nd change
none
darkened / fixed patch.
none
latest version
none
gnome - industrial 'old-style'
none
gnome - industrial 'new-style'
none
gnome - default theme 'old-style'
none
gnome - default theme 'new-style'
none
gnome - high contrast 'old-style'
none
gnome - high contrast 'new-style'
none
Windows XP - Windows XP Theme, Default color scheme
none
Windows XP - Classic Theme, Windows Standard color scheme
none
Windows XP - Classic Theme, High Contrast White color scheme
none
gnome industrial new (updated)
none
gnome default new (updated)
none
gnome high contrast new (updated)
none
last word patch (?)
none
photo of gedit vs. OO.o insensitisation
none
pinky icons none

Description mmeeks 2004-10-14 16:32:58 UTC
The attached patch (which looks big, but is an overall code reduction I think)
re-works the GUI insensitisation code, producing a far prettier result -
particularly with deep-colour / alpha icons (which tend to not convert to 1 bit
masks well).

It performs no-doubt somewhat worse than the previous 31337 optimised version -
however, there are only a few insensitive icons on the screen at any given time,
we're now working with individual icons instead of huge icon strips typically &
gtk+/gdk-pixbuf gets away with this level of floating-point math to give a
perceptually nice result without noticable performance issues.
Comment 1 mmeeks 2004-10-14 16:33:30 UTC
Created attachment 18401 [details]
a patch
Comment 2 philipp.lohmann 2004-10-14 16:59:31 UTC
kai, could you please evaluate this patch ?
Comment 3 ooo 2004-11-25 10:35:46 UTC
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.
Comment 4 mmeeks 2004-11-26 04:11:23 UTC
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.
Comment 5 mmeeks 2004-11-26 04:11:59 UTC
Created attachment 19718 [details]
the 2nd change
Comment 6 mmeeks 2004-12-14 14:15:01 UTC
Kai - any further advance here ? I attach the full re-worked patch in case it's
at all helpful.
Comment 7 mmeeks 2004-12-14 14:15:42 UTC
Created attachment 20506 [details]
darkened / fixed patch.
Comment 8 ooo 2004-12-15 10:36:57 UTC
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.
Comment 9 mmeeks 2005-06-15 10:37:37 UTC
A new version minus WriteAccess / ReadAccess leaks 
Comment 10 mmeeks 2005-06-15 10:38:12 UTC
Created attachment 27193 [details]
latest version
Comment 11 mmeeks 2005-11-14 17:45:14 UTC
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 :-(
Comment 12 mmeeks 2006-03-21 10:54:44 UTC
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 ;-)
Comment 13 billhaneman 2006-03-21 13:09:26 UTC
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).
Comment 14 lutz.hoeger 2006-03-21 13:50:31 UTC
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).
Comment 15 mmeeks 2006-03-21 14:20:51 UTC
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 ? :-)
Comment 16 mmeeks 2006-03-21 14:37:27 UTC
Created attachment 35095 [details]
gnome - industrial 'old-style'
Comment 17 mmeeks 2006-03-21 14:37:48 UTC
Created attachment 35096 [details]
gnome - industrial 'new-style'
Comment 18 mmeeks 2006-03-21 14:38:17 UTC
Created attachment 35097 [details]
gnome - default theme 'old-style'
Comment 19 mmeeks 2006-03-21 14:38:32 UTC
Created attachment 35098 [details]
gnome - default theme 'new-style'
Comment 20 mmeeks 2006-03-21 14:38:55 UTC
Created attachment 35099 [details]
gnome - high contrast 'old-style'
Comment 21 mmeeks 2006-03-21 14:39:17 UTC
Created attachment 35100 [details]
gnome - high contrast 'new-style'
Comment 22 mmeeks 2006-03-21 14:43:18 UTC
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.
Comment 23 tml 2006-03-21 14:56:08 UTC
Created attachment 35101 [details]
Windows XP - Windows XP Theme, Default color scheme
Comment 24 tml 2006-03-21 14:58:02 UTC
Created attachment 35102 [details]
Windows XP - Classic Theme, Windows Standard color scheme
Comment 25 tml 2006-03-21 14:59:10 UTC
Created attachment 35103 [details]
Windows XP - Classic Theme, High Contrast White color scheme
Comment 26 lutz.hoeger 2006-03-21 16:08:16 UTC
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?
Comment 27 mmeeks 2006-03-21 17:19:25 UTC
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.
Comment 28 philipp.lohmann 2006-03-21 17:28:47 UTC
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.
Comment 29 mmeeks 2006-03-21 17:51:34 UTC
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.
Comment 30 lutz.hoeger 2006-03-22 09:02:03 UTC
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?
Comment 31 mmeeks 2006-03-22 09:50:22 UTC
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).
Comment 32 mmeeks 2006-03-22 11:57:30 UTC
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 ].
Comment 33 mmeeks 2006-03-22 12:32:54 UTC
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.
Comment 34 mmeeks 2006-03-22 12:33:48 UTC
Created attachment 35123 [details]
gnome industrial new (updated)
Comment 35 mmeeks 2006-03-22 12:34:09 UTC
Created attachment 35124 [details]
gnome default new (updated)
Comment 36 mmeeks 2006-03-22 12:34:30 UTC
Created attachment 35125 [details]
gnome high contrast new (updated)
Comment 37 mmeeks 2006-03-22 12:35:23 UTC
Created attachment 35126 [details]
last word patch (?)
Comment 38 mmeeks 2006-03-22 14:33:50 UTC
Created attachment 35131 [details]
photo of gedit vs. OO.o insensitisation
Comment 39 ooo 2006-03-22 15:25:59 UTC
added KA to Cc list
Comment 40 mmeeks 2006-03-28 14:50:32 UTC
a week passes responselessly ... ;-)
Comment 41 lutz.hoeger 2006-05-19 11:50:16 UTC
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?
Comment 42 mmeeks 2006-05-19 12:32:08 UTC
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.
Comment 43 ace_dent 2006-07-13 03:45:21 UTC
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
Comment 44 pavel 2006-08-22 09:55:48 UTC
move target to next version because of code freeze.
Comment 45 pavel 2006-11-06 14:45:13 UTC
move target to later version because of code freeze.
Comment 46 stx123 2006-11-10 10:00:53 UTC
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.
Comment 47 lohmaier 2006-12-18 15:40:16 UTC
/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€...
Comment 48 rail_ooo 2007-03-21 13:37:30 UTC
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.
Comment 49 rail_ooo 2007-03-21 13:39:44 UTC
Created attachment 43833 [details]
pinky icons
Comment 50 ht990332 2007-06-24 13:20:15 UTC
Can someone please update the patch to apply to src680_m217 ? 
thanks in advance.
Comment 51 mmeeks 2007-07-04 11:44:14 UTC
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/
Comment 52 thb 2007-08-26 21:48:29 UTC
@mmeeks: fyi - just got this 80705 issue.
Comment 53 Marcus 2017-05-20 11:29:20 UTC
Reset assigne to the default "issues@openoffice.apache.org".