Selecting text is done, focusing still remains.

Adding GNOME2 keyword to all keynav bugs per sander's request. You can filter on
the phrase 'luis doing GNOME2 work' to catch all instances of this so that you
can ignore them.

I have no idea how focus for selectable labels should work...
should they just be in the focus tab chain.. might be pretty
confusing.

I don't think they should be in the regular tab chain, unless they're
only used in a very few places.  A couple of options that I mentioned
on gtk-devel are below... they're not great, but apart from "put them
in the tab chain", they're the only ones I've seen so far :)

1. Only allow keyboard selection of labels that have an access key,
and have a 'special' access key mechanism for focusing them, e.g.
Ctlr+Alt+mnemonic rather than the usual Alt+menmonic (which would
normally focus the control the label referred to, if it had one). 
Once such a label had focus, pressing Tab/Shift+Tab would just move
focus to the next/previous control as usual.

Unfortunately, the most useful labels to select are usually messages
in alert boxes and suchlike, which would probably look odd with an
underlined letter in them, so another alternative could be:

2. Have Tab cycle through every control in a dialog except selectable
labels (as it does right now), and Ctrl+Alt+Tab (or something, but
there aren't many unused combinations left that include Tab) cycle
through everything in a dialog *including* selectable labels.

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

the control-alt-tab suggestion is easy enough to implement messily,
hard-coding the modifer (just check the modifier state, in
gtk_label_focus()), but quite a pain to implement  cleanly.  

Unfortunately Ctrl-Alt-Tab is now used for cycling between panels, so
we'd need to think up another shortcut for this...

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 :)

Any word on which shortcut to use for this?

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

Hrmm, I'm convinced I added a comment to this last week :/

Anyway, all the sensible <modifier>+Tab combinations are now taken, so
despite my previous reservations I'd be inclined to say that just
putting them in the regular tab chain might well be the best bet
now... selectable labels should be pretty rare in most regular
dialogs, so any negative impact ought to be negligible.

I'd agree that just putting them in the regular tab chain could work.
 Before this is commited I think a separate bug needs to be filed with
the HIG that has a section warning against using these often, or at
least in situations where they become confusing.  Ugh, that's such a
general statement; confusing as discussed above.

See bug #133423 for the HIG.

Fixed on CVS.

2004-02-04  Federico Mena Quintero  <federico@ximian.com>

	Fix #59707.

	* gtk/gtklabel.c (gtk_label_focus): Removed, so we don't ignore
	the focus chain.
	(gtk_label_button_press): Fix prototype.
	(gtk_label_button_release): Likewise.
	(gtk_label_motion): Likewise.

	* tests/testgtk.c (create_message_dialog): For the dialog with
	only GTK_BUTTONS_CLOSE, make GTK_RESPONSE_CLOSE the default.

This checkin is going to break A LOT of apps. The HIG currently 
recommends making the text in error/alert/info dialogs selectable (so
the user can copy and paste the msg). 

With this change, the default focused item will be the first selectable
text item whereas before it would be the default button at the bottom
(like OK or whatever). This is not good.

I think this change should be delayed until after branch for gnome 2.4
to give maintainers a good chance to catch up.

Fair point, the intention for alerts would still be to have the
default button be the first control focused.  Unless there's a way to
patch GtkMessageDialog itself to ensure this always happens (and
presumably even that wouldn't catch everything), I'd agree it might be
worth delaying.

All gtkmessagedialogs in existing apps are broken now, since the label
is selectable by default in those. Other dialogs like gnomeabout is
broken as well. Plus a lot of custom dialogs in apps everywhere I'm
sure. Shouldn't this be reopened?

Yeah. This sounds pretty damn bad.

Reopening as suggested, sounds like we might want to revert this one
for a while.

I think using a different tab-combination would be much nicer than 
just dumping the labels in the regular focus chain. If the clash with 
pane switching is really a problem, we could provide an alternative 
key combination not involving tab (we do something similar for 
Ctrl-PgUp which also has some conflicts). 


Calum, do you have an "inverted keybindings table", ie one mapping key 
combinations to their uses ?


Another (worse) alternative would be to make this a mode.

There really is no sensible Tab combination left:

[Shift]-Tab: moves focus between controls
[Shift]-Alt-Tab: moves focus between windows
[Shift]-Ctrl-Tab: moves focus between controls that eat Tab
[Shift]-Ctrl-Alt-Tab: moves focus between panels/desktop

So we're really only left with Hyper/Super/Meta, which I think would
be a bad idea :/

99% of selectable labels will be in alert boxes, where focus should
initially be on the default button anyway.  So in theory I don't think
there should be a problem with them in the tab chain, and it's
certainly the most discoverable option for the user.  It does mean
fixing all existing alert boxes somehow as Richard pointed out, but
IMHO we shouldn't use that as an excuse to invent yet another obscure
keybinding :/

Would there really be a conflict with reusing Ctrl-Tab ? 


Seems to be almost explainable: Use Tab to move the focus, if you get 
stuck, or if the focus doesn't want to move to a label, use Ctrl to 
make GTK+ try harder...

Using Control-Tab sounds plausible to me, but making alert boxes
automatically fixed without application writer intervention
is not hard, if quite hacky, just in gtk_dialog_map() extend 
the logic to never leave a label focused. (With care not to infinite 
loop if there are no focusable widgets other than labels.) 

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

Hmm, okay, I agree that the Ctrl-Tab suggestion doesn't conflict with
its existing use, but it would place two fairly different interaction
models onto the same shortcut.  Also there would be no way to tell
which labels were focusable unless you used Ctrl-Tab to move focus all
round any particular window.  Even assuming that's currently possible
(does Ctrl-Tab always move the focus when Tab would?), if you're going
to have to do that anyway, wouldn't it be easier just to use Tab? :)

Can this be added to the willfix list for 2.4?

If not, i suppose the original patch should be backed out.

Note that GnomeAbout is an example of a case where the 
MessageDialog specific fix doesn't help and a label
ends up focused.

Did we reach consensus on this? I.e. should we start fixing things
like GnomeAbout? It's getting dangerously close to release now.

Far too many apps are ending up with the wrong widgets focused
in dialogs; I've backed out the previous changes and instead
made a (slightly hacky but functional) change so that GtkLabel
is in the tab chain only when 

Thu Mar 11 13:58:24 2004  Owen Taylor  <otaylor@redhat.com>
                                                                     
          
        * gtk/gtkmessagedialog.c gtk/gtklabel.c: Back out the
        put-labels-into-the-standard-focus-chain patches
        from bug #59707.
                                                                     
          
        * gtk/gtklabel.c (gtk_label_focus): Only put the
        label in the tab chain when the control key is pressed.

does this conflict with the existing behavior of Control-TAB? I though
control TAB was reserved for moving focus out of TAB-grabbing contexts.

See discussion above; basically Control-Tab can be interpreted
as "focus harder". This is far from perfect; you can get problems
like where escaping from a control ends you up on a selectable
label. But the alternative was causing a lot of problems in
GNOME dialogs; this at least gives *some* way of focusing
the selectable label in the GNOME-2.6 timeframe.

thanks Owen; sounds good, though I haven't tested it yet.  I'll leave
the conclusions to Calum.  Thanks for having a go at this for 2.6,
it's very helpful.