high visibility bug in an embarassing place, therefore AP2 (otherwise
would be AP3)

in gnome-about, the part of the screen where the text and background
does not respond to theme changes is written as gnome_canvas in a
gdkpixbuf. Since gdkpixbuf is a layer below gtk/gdk, I don't think
there is an easy fix to this bug unless the app is rewritten.
(see also gtk-demo under gdkpixbuf option)

But I can't seem to think the value add in rewritten an apps such as
gnome-about which only list the list of contributors in a fancy way.

Hmm... could potentially be reasonably important to fix somehow, as
some distros (e.g. JDS) put licensing information here too.  I guess
that could always be provided elsewhere instead, though.
  
Since it sounds like there's no painless solution to this, I suspect
we might just have to live with it for 2.6 :/  The only other thing I
can think of would be to provide a 'regular' about box as well (like
you get in other applications), and provide a gconf key or something
for distros to set which one gets displayed when you select "About
GNOME".  But that goes somewhat against our mantra of 'you shouldn't
need to do anything special for accessibility to work'...

Any GUI rewrite will involve a GUI changes which is probably not
acceptable at this stage of the release cylce, or is it?

The functionality is non-essential, that's true.  The problem is that
all users of inverse themes will see this high-visibility bug sooner
or later.  So, how much weight to give the bug on the basis of its
high visibility?

I believe that until hard UI freeze this week, there is a window of
opportunity to fix this bug.  A rewrite might not be that enormous -
in fact, since the GtkStyle foreground and background colors should be
relatively easy to obtain, I don't see why the canvas can't use these
colors for foreground and background when drawing the text etc. into
the about box.  IOW, I don't think a rewrite is necessary to fix this
bug.

After some study of the code, the biggest problem with making a fix
based on what billh suggested is that gnome-about uses a white
background so that the black to grey text can be properly animated.
(Notice that the white background does not change regardless of theme
changes be it a reverse mode or not) Removing this white background to
use the default theme background exposes some pretty ugly side effect
on the animated names.

So I CC: Gman MarkMc, jdub and Malcom whose names are in the
gnome-about.c file. Should the gnome-about white background not use
the default background instead of hard coded to WHITE.

Okay. after spending another days on this.I can easily change this to
respect the theme by removing the WHITE background and the scrolling of
name without some ugly tracing boxes. 

However getting the whole of current gnome-about to reponse to
- font sizes
- text colour
- proper links to be captured by GOK
are the changes needed to make gnome-about to be truly accessible. The
changes are huge.

This app is not designed with accessibility in mind because the
current accessibility framework just does not work well a the
gnome_canvas level. One has to hack around some many pieces of
gnome_canvas_item, the code just gets into a mess.

I think a proper solution is to redesign the app and for accessibility
to work, just drop the 'flying' hackers.

Ghee: I tend to agree that redesigning the app might be less work.

However, the various issues you raise regarding 'complete'
accessibility may have different priorities.  As long as keynav of
some sort is available for all gnome-about actions (including link
following), we can have nominal accessibility with a few theme-related
changes.

Sounds to me as if you've got text and background color issues solved
- so I don't see why you mention text color above (if you can fix the
background color issue, why not the text color?  Isn't it potentially
as simple as setting the GtkGC used to render the text?)

Font size - arguably this is not important for the 'flying hackers',
and it seems that we should be able to base the other text sizes
pretty easily from the current font settings.  I don't see why this is
"huge".  And if the links are not keyboard navigable, that's really a
stopper (that's a core requirement for all our accessibility, and one
that we probably cannot ignore even for the About box).

regarding the links: it occurs to me that we could provide an F10
keybinding that treated them as though the horizontal list of links
were a menu bar.  That would avoid the need to implement AtkHypertext,
etc.  Similarly, if we created a context menu for gnome-about, which
was exposed as an action on the toplevel accessible, we could put all
the links there.  We could then avoid the necessity to make the links
keyboard navigable since we'd have equivalent functionality available
from the keyboard.

Bill, two things.
(1) Since the gnome-about is written with many of the gnome_canvas and
item, each of the 'item' on the dialog is created as a local variable
which if we are to handle "style-set" event in one go, all these local
variables will have to be organised into one place. Hence, the 'huge'
changes in terms of code reorganisation rather than difficult. 

The difficult bit is though that the animation changes is based on a
fixed size dialog when the name of the hackers reduces/increases
pending the position on the text. When the font changes size, the
whole position changes and need to be re-calculated.

(2) On the links issue, I don't know how GOK works to grab the action
on a window. Though I think these links are the only other useful
services provided to the users other than the license term. These are
gnome_canvas_item (), why can't GOK grabs a gnome_canvas_item ?

Although I have been recently CC'd on this bug, I cannot really
contribute substantively. However, I can think of no reason why it
shouldn't respect the theme (although my contribution to the code had
nothing to do with the canvas setup).

But, seriously, gnome-about has severe usability problems and the
presentation of contributors' names needs to be redesigned in GNOME
2.8 (I wanted to do it for 2.6, but time got away from me -- three
months is not as long as it should be sometimes).

Created attachment 24230 [details]
modfied demos/gtk-demo/appwindow.c

Malcom,
Thanks for the update :) appreciated for the info.

Bill,
The root cause of the problem seems to be in 2 parts with regards to
the foreground and background colours.
(1) All the hard coded colors within gnome-about, which I am going to
create a patch to address this.
(2) There is another problem with the hc-reverse theme itself.
I tried print out the value of the fg colour and it is always
( 0 0 0 ) which is black. Hence, the colour theme for reverse
 does not work.

Attached is the modified gtk-demo program.

Created attachment 24236 [details] [review]
gnome-about patch

The attached gnome-about patch fixes the following problems:
- The background and foreground colours honour theme changes correctly
- For HC-Reverse theme, I believe there is a bug outside gnome-about
  therefore, despite it honours the theme changes, the text is not
  very visible
- I also removed the colour animation for the contributors and only 
  keeping the size animation. The reason for doing so is that now we
  are using the theme color rather than the black colour as standing
  point which produces some jumping behaviour based on the default
  foreground color.

- Apart from the start, this patch is simply removed the hardcoding of
  color and let the theming engine does the rest.

Please review the patch and see this can be committed.

ghee: I suspect the visibility problem with inverse themes has to do
with how antialiasing works for white text on black (not very well!).

Perhaps the HighContrast themes should be able to turn off
antialiasing, or at least select a more visible form.  Do things
improve if you change the smoothing/antialiasing settings in the Font
capplet?

Bill, unfortunately setting to no antialiasing or not has no effect on
the foreground color. It is still black when it is supposed to be white
in the HC Reverse Theme.

I did not understand your comment - I thought you were talking about
antialiasing problems.  Can you please explain the issue in more
detail (about which you say there 'is a bug outside gnome-about' ?)

Created attachment 24242 [details]
screen-shot in highconstrat reverse theme

Bill, see attached screen shot. You should see lots of black text
behind the blue background. I tested the app as well as with the gtk+
demo app, it seems like doing

- wid = gtk-new-widget();
- style = gtk_widget_get_style (wid)
  g_print ("gtkstyle fg color: ( %d %d %d )\n",
                   style->fg[0].red, style->fg[0].green, 
                   style->fg[0].blue);

I would expect that value to be 65535, 65535, 65535 but instead I got
0,0,0.

This is what I meant the bug lied outside gnome-about.Could be in the 
theme engine or else where.

Ghee: obviously the GtkStyle does work with inverse themes in the
general case.  So, question is, what's different about your test case?

oh also - Ghee, text is normally drawn in text_gc on a background of
base_gc, not fg_gc over bg_gc.  However for HCI themes both text_gc
and fg_gc should be white and base_gc and bg_gc should be nearly black.

Okay, looks like progress is being made. The patch looks reasonably
sane to me, but obviously we want it actually working nicely under the
various themes before committing.

ghee, any progress in tracking down the problem with text color (0,0,0) ?

We are only days from 2.6 code freeze.  Is this bug still being worked on?

No was done to this over the last 2 weeks...I am afraid :)

what is the plan for resolving this THIS WEEK ?  thanks.

Okay. While I found out what is the major difference why the
gnome-about is not behaving properly. 
The problem is that many of the text used in this dialog box are of type
gnome_canvas_text which provides Markup text support, but does not
take into consideration for gtkstyle changes. By comparison, the
scrolling license text is based on gnome_canvas_rich_text which does
not provides the Markup text support does have code to take into
consideration of gtkstyle colors. The question is how can
gnome_canvas_text be modified to consider the gtkstyle values?

Looked a bit more in gnome-canvas-text.c where the gtkstyle stuff
should be stuck in. But it seems non-trivial. So if anyone else want
to pick it :)

Do we really need the markup in the (gnome-canvas-text) gnome-about
text, or can we provide it another way (via gnome_canvas_rich_text)?

Created attachment 26259 [details] [review]
Patch to get the text color working on theme change 

Took Ghee's patch and added the fix for foreground text color changes. All the
foreground text respond to the theme changes, except the introductory messages
only in a partcular scenario. The foreground color changes don't get reflected
on these intro messages only when we have the dialog up and we change the
theme. This is because the intro messages are put using gnome_canvas_rich_text.
At this moment there is no property to set the color. I am looking in to this.
In the meantime kindly have a look at the attached patch.

Bugzilla bug #139485 has a patch for the remaining issue mentioned above

I haven't looked at the patch in great detail, but I've tried it out. I think
its fairly sad that we can't figure out a way to use a white background - grey
looks really dull in this case

I'll look at it more after we branch

If gray is being used when HCLPI theme is in used, then the patch isn't working
correctly; HCLPI should be using white text on a nearly-black background.
If a "dull grey" is appearing using 'default' themes, then probably the
gnome-canvas is using bg_gc where it should logically be using base_gc.

Yes I think this part of the patch is wrong:

+	for (l = list_item; l; l = l->next) 
+		gnome_canvas_item_set (GNOME_CANVAS_ITEM (l->data),
+				       "fill_color_gdk", GTK_WIDGET (canvas)->style->fg, NULL);        
+}

This should be using (canvas)->style->base.

sorry for repeated serial comments, but something else possibly important
occurred to me: gtk+ "normally" uses a style that gives GtkTextView and GtkEntry
a different base gc from other widgets (i.e. 'white' or nearly white).  So if
fixing the patch above to use base doesn't solve the 'grey background' issue,
then we may need to grab the style info for GtkTextView and shove that GdkGC
into the canvas fill color call instead of use the default canvas fill color.

Hard-coding the canvas fill color ignores the canvas style, probably the desire
to "whiten" it is what partly led to the theming problems in the first place.

Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs.
 Filter on "SUN A11Y SPAM" to ignore.

Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.

The patch still applies (except for the ChangeLog entry) and fixes the bug except for the GNOME foot icon (I guess we need a HCI variant of that logo). Can it be applied for 2.20 ?

gnome-about has been rewritten in python and doesn't use a canvas anymore. This bug is fixed now. See bug 481585 for more details.

Created attachment 99984 [details]
gnome-about-mockup-all.png

Having a themed gnome logo with some backgrounds it produces unexpected results (and, I think, also not compliant with the logo guidelines[1]). I have made a couple of mockups to mimic the branding used in gnome-system-monitor (indeed not sure about the result :).

[1] - http://live.gnome.org/BrandGuidelines?action=show

Luca: the bug here is that we're using a image header, which is breaking stuff anyway. See bug 125293.