The patch was applied.. the main problem here now is that
the result looks bad -- the default should not be to use the
stipple... we already use different methods of indicating
focus for different widgets. See also notes in:

http://mail.gnome.org/archives/gtk-devel-list/2001-December/msg00018.html

I disagree, about the result looking bad.  For accessibility reasons
we need to use a consistent method of showing focus, with few if any
exceptions (for instance, using PRELIGHT or such for showing focus in
container widgets which are awkward to contain with a focus box).  
There is no point in having a themed focus drawing mechanism if it's
ignored by the default theme :-)  Even in the case of text, where we
use a text caret for focus indication, we can show a focus rectangle
using the standard drawing routines by setting exterior focus.
The only alternative that I think would be acceptable would be to
create a "use consistent focus drawing" property that ould be set to
TRUE by accessibility themes.

CHanging the summary back.  It's really not reasonable for a
non-reporter to change the summary of a bug report in such a way as to
invert its meaning :-)

Would you prefer if I resolved your bug as FIXED and filed another?
I guess we need a statement somewhere "All bugs filed against
the GTK+ component become the property of the GTK+ team"
or something :-)

It's absolutely ridiculous that the default theme shouldn't
look as good as it can because some idea that it isn't 
"consistent".

I actually believe there is no reason to obey the dash style
property at all for the colorsel, and I don't think it will
ever look good to do so, but I wasn't proposing doing so;
the implementation method might be as simple as installing
a default theme RC file (we need to do so for other reasons
anyways.)

Bill asked me to have a quick look at this to see what I thought from
a usability perspective... he showed me how it currently looks, and a
few alternatives, so here's my thoughts.

I have to say that using a solid line to indicate focus didn't, to me,
look sufficiently better (in either the 'prettiness' or 'obviously
focused' senses) than a dashed line of equal thickness to warrant
being drawn differently from the focus on the majority of other
controls.  The two problems (one real, one potential) I see are:

1) The focus line is drawn too close to the perimiter of the
outer/inner rings, so it interacts with them to create aliasing, and
renders the focus indicator virtually invisible until you move it. 
This is a problem with whatever style of focus line we use-- is it
possible to make the rings a few pixels smaller in diameter so there's
clear space between the rings and the focus indicator?  (Ideally the
space should be constant whatever focus indicator width is specified
by the theme, but I guess 'a few pixels' might be enough).

2) If one was just looking at the window trying to work out what had
focus, a solid line focus indicator could easily be interpreted as
being as part of the control itself, since many controls are bounded
by a solid line anyway in their unfocused state.  I'd bet a lot of
people would have to "press Tab and see what moves" to work out what
had focus, which isn't ideal-- especially as the text in the Color
Name field confusingly stays highlighted once you've tabbed through it
once, until you change its value, so it often looks like it's that
control that has focus.  This violates the principle that the focused
control should always look focused, and everything else in the window
should look clearly unfocused.

If 1) isn't possible, IMHO the best alternative Bill showed me was a
thicker dashed line (2 or 3 pixels, I forget which now).  This would
still be inconsistent with focus indicators on other controls in terms
of its thickness, but its "dashed-ness" would probably communicate the
idea of focus better than a solid line (even a thicker solid line),
since other controls use a dashed line to show focus too.

To be honest, though, it's probably going to look kind of ugly
whichever way you do it, unless you can actually anti-alias the focus
ring itself.  Just my .02 euro cent[s]  :o)

Calum, Owen:

I think a one-pixel pad should help with the aliasing... I propose
that we make a change to insert that padding as you suggest, and then
consider whether the 'default' gtkrc theme (which may need to be
reinstated as Owen suggests) should specify a different
focus-line-width or focus-line-pattern once the padding is added. 

Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.

Moving a number of non-critical or hard-to-fix bugs to 2.2.0

Updating status_whiteboard field to reflect A11Y team's assessment 
of accessibility impact.

Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME
bug list :)

*** Bug 131092 has been marked as a duplicate of this bug. ***

Created attachment 23244 [details] [review]
patch

I tried implementing padding between the widget and the focus line,
and it did not materially improve the appearance of the widget;
it turns out that the uglyiness is not aliasing/collision as much as 
simply the fact that dashed-circles look really ugly with the X 
primitives.

(No screen shot, sorry, I threw away the changes before I thought
of making a screen shot)

Things only looked even close to OK good when I increased the focus 
pattern length to an extent that there was no more visual connection
with the standard focus style and line width than there is with
a solid line.

I'd really like to make the GTK+ default theme use a solid line for
this - put in your ~/.gtkrc-2.0:

===
style "gtk-hsv-style" {
  GtkWidget::focus-line-width = 1
  GtkWidget::focus-line-pattern = ""
}
                                                                     
          
class "GtkHSV" style "gtk-hsv-style"
====

to test. I think it looks pretty good even without antialiasing,
and while it may be less "standard" it's actually visible,
which the current ragged line isn't.

Of course, basically nobody uses the default theme these days,
so what the default theme does doesn't really matter much...

The antialising changes from bug 131092 or bug 112470 I don't
think are that useful because:

 - I want to preserve the ability to have a pattern, and neither
   supports the pattern

 - While we could only antialias without the pattern, I think
   the appearance without a pattern is reasonably OK aliased;
   so it's not worth throwing in a bunch of special-case code 

I'm going to put this on 2.4.1 for the simple change of making
the default theme use a solid line. Anti-aliased drawing, I think
we should wait for Cairo for, which is GTK+-2.8 most likely.

I think Calum's point about the "focus indicator" not directly
touching the circle is right on. The problem is that having black
lines around the edges of things just looks like a "border" not
"focus". The dotted version lying right next to the circle, to me,
just looks like an even more poorly drawn/jagged border.

Created attachment 25611 [details]
Mockup of an entirely different idea

That is much more stylistically consistent with our existing focus
indicators, and is probably more likely to be noticed. 

IMO it also looks better than a jagged circle.

That's only an alternative for the jagged triangle, though, we would
have to figure out how to do something similar for the jagged circle
as well.

The idea of the two mockups is that we'd draw a box around the
whole area to indicate focus on the ring, and then the box around
the marker to indicate focus on the triangle.

FWIW I like the look of this new direction too.  My primary a11y
concern is that visibility is improved when larger focus-line
thickness is requested.

Comment on attachment 23244 [details] [review]
patch

Marking needs-work; sounds like owen wants a different tack. Please kick my
butt (louie@ximian.com) if I'm wrong :)

Created attachment 35125 [details] [review]
Change ring marker to circle, show ring and triangle focus similarly

This patch changes the ring marker to a circle, and shows focus the same way
for
both the triangle and the ring. It feels a bit more natural than the
alternatives, IMO. A further improvement would be to hide the focus highlight
during mouse drags. (The patch is against Gtk 2.6.0, by the way)

Comment on attachment 23244 [details] [review]
patch

Original description was too long for the soon-to-be-upgraded Bugzilla.