1) Why do you need the menu, isn't the model enough to present the 
available options to ATs ?




2) Should be as easy as exporting gtk_combo_box_pop{up,down}.




3) No entry inside, its a GtkCellView AFAICS. Why do you need it,


considering you can get/set the active iter ?

1) When an AT sees a object with role combo-box it expects them to
appear in a similar way. Currently we have GtkCombo and GtkOptionMenu
and Java's JComboBox.

The conevntion used is that the first child of a combo-box contains
the menu or list which may be popped down and the second child is the
text entry field if the combo-box has one.

3) A GtkComboBoxEntry does have a GtkEntry. It is needed to report the
text in it and the location of the text.

I have noticed another problem: When the GtkComboBox menu is popped
down it is not possible to report the text in a GtkCellViewMenuItem.
Thus a screen reader will have a problem reporting the menu items to a
blind user.

I don't understand the response for 1). There is no guarantee
that a GtkComboBox will always have a menu .. the intention
for the future is that some themes may present a Windows-style
list. I think it's best to expose whatever functionality
that ATK needs in the GtkComboBox interfaces rather than
letting it drill down and manipulate the menu. 

How much API would you need for that?

For 3) gtk_bin_get_child() provides the child of GtkComboBoxEntry.

I assume that the GtkComboBox will always have something, e.g. a menu
or list on which selection can be done. I would like access to that
object.

Padraig, I've made gtk_combo_box_popup/down public now. 

Thanks.

I still have two problems with make GtkComboBox accessible:

1) I am unable to get at the popup widget in order to represent it as
a child of the accessible object for the GtkComboBox.

2) I cann get the text in a GtkCellViewMenuItem. I need this so that
when the menu is popped up gnopernicus can read it to a blind user.

Padraig, I still don't see why you insist on getting a "list-like" 
widget (which may be a private thing and won't make you happy). Why 
can't you get the necessary information from the tree model + cell 
renderers ? How is accessiblity handled for treeview ? 

I explained above why I think I need it.

I do not see the harm in having a function
gtk_combo_box_get_popup_widget().

The implementation for treeview is in gailtreeview.c. A GailTreeView
object which is an AtkObject is created for the treeview. It
implements AtkSelection, AtkTable and AtkComponent interfaces. A
GailCell object is created for each cell, i.e. row, column pair, if
required.

The popup_widget might be a private widget.

What does "private widget" mean in this context?

No installed header, like e.g GtkHSV.

This should not matter from an accessibility point of view. I expect
to be calling gtk_widget_get_accessible() on it. As the widget will
appear on the screen if the user pops down the combo box we will need
to be able to deal with it from an accessibility point of view.

But I think it would be awkward to have an API which returns private 
widgets. Maybe we can add a gtk_combo_box_get_popup_accessible() 
method for you, which directly returns the accessible of the popup, 
whatever its type. But who would be responsible for creating the 
accessible for that widget ? I thought there was a problem with 
putting accessibles for private widgets into gail, didn't we discuss 
this for GtkHSV ?

This subject of GtkHSV and accessibility is bug #132745.

My view is that if the .h file is not available to gail then the
accessibility implementation for the widget will need to be in the
widget's source file; this is the approach taken in Java and in eel
and some other parts of GNOME. I note that Owen has not commented on
that.

Do we currently have a private widget or this this something which may
happen in the future?

Currently it seems to be either a menu or a window containing a frame 
containing a treeview. I thought there was a GtkCellView (which is 
private) involved, but the cell view is the widget left of the arrow. 

Padraig, I discussed location of a11y implementations with Owen 
yesterday, and there are no principle objections to doing a11y 
implementations for new widgets inside gtk. 


Maybe we can test-drive this with the combobox widget, and avoid 
exposing the guts of the widget in the api.

As far as I can se the only issue with GtkCOmboBox is the need for a
function such as gtk_combo_get_popup_accessible(). If we were to move
accessibioity support for GtkCOmboBox within the widget it would
require moving the code in gailcombobox.c tp gtkcombobox.c. Would it
be better to just provide the function
gtk_combo_get_popup_accessible() rather than have to deal with the
issues of moving that code just as you are trying to finalize GTK 2.4.

The more worrying problem from my point of view is getting the text
displayed in a GtkCellViewMenuItem. I do not think that this is
possible even in gtkcellviewmenuitem.c as GtkCellView isa opaque in
that it does not seem to be possible to get the text specified in a
call to gtk_cell_view_new_with_text.

And we get the accessible to return by calling 
gtk_widget_get_accessible() on the popup, I assume ?

Yes.

We're still worrying about exposing different objects depending on the
style, regardless wether they are widgets (via get_popup()) or
accessibles (via get_popup_accessible()). Therefore, we will have to
put this to 2.4.1. Hopefully, Padraig can work with us to get an
accessible implementation for the combobox inside libgtk, so that we
can avoid questionable api. Here is the discussion leading to this
decision:

<maclas> owen: the latest info from padraig is that he just needs a
way to get at the accessible object of the popup + a11y support for
the cellview
<owen> Well, that's what he said earlier, too, right?
<maclas> owen: yes, more or less. But its now much clearer that the
bigger issue is the cellview. gtk_combo_box_get_popup_accessible()
would be trivial
<owen> I don't think we care whether he can get at the widget for the
popup or th accessible object of the popup, what we are worried about
exposing is "its' a menu" vs. "It's a list" and that distinction is
there whether you get the widget or accessible
<owen> maclas: Sure, the cellview is an issue, but do we have any idea
of what the exact proposal is being made? Did we find out how gailis
handling GtkTreeView?
<maclas> owen: i din
<maclas> owen: i didn't look much further, since I don't think we can
implement that before 2.4 anyway. 
<maclas> owen: regarding the get_popup_accessible(): it is certainly
not nice to return different things depending on the style, but since
it is an _accessible() function, its pretty much a gail-only api...
<owen> maclas: Did you catch what I was saying yesterday about this
percolating down to AT impleentations?
<owen> maclas: (s/yesterday/a couple of days ago/)
<maclas> owen: I don't recall anything about percolation...wasn't here
yesterday
<owen> maclas: What I mean is that GAIL will expose "It's a menu" to
ATK, ATK will expose "It's a menu" to AT-SPI, the AT implemention
(e.g., the screen reader) will assume that get_accessible always
returns a menu
<maclas> owen: ah, I see. Well, I was kind of assuming that if we
return a "menu accessible" or a "list accessible" (actually, it would
the accessible of a window), that gail would provide an adapter to
handle this and make sure that AT implementations always see what they
expect. 
<owen> maclas: Well, it *might* happen...
<maclas> owen: the easier alternative is to declare that combobox a11y
has to wait until 2.4.1, and then get Padraig to provide us with an
accessible implementation to include in gtkcombobox.c; I think he's
away for two weeks now
<owen> maclas: I think doing that is best. I'm not sure we can sort
out the cellview stuff without him properly anyways.
<maclas> owen: its certainly not nice to regress in this way, but its
probably unavoidable now; adding get_popup_accessible() won't give us
an accessible combobox anyway without the cellview stuff...

an inaccessible gtkcombo for gnome-2.6 is not a nice thought.  I think
we need to do something to prevent regression from gnome-2.4/gtk-2.2
even if it means not doing things exactly as we'd like.

I don't understand the concern about 'assumptions' from the AT client;
maybe there's a misunderstanding here.  Depending on the object type
gail gets internally in response to its (internal) query, it will
expose a different ATK_ROLE/SPI_ROLE to the client; so there should be
no assumption about this always being a menu, as opposed to a
table/list, etc.

I think the right thing to do is expose gtk_combo_get_popup() on
gtk_combo, and have gail use type reflection to determine what kind of
object it is.  For 2.4.0.  This is marked as a candidate stopper for
accessibility, meaning that we think it may be serious enough to block
release (ok, block any claims for accessibility of the release). It
does however fall short of the "definately too broken" category.

My point is that if in testing the popup widget from a GtkCombo
is always a menu, this assumption is going to get implicitely
hardcoded into the AT. If the user then changes the theme and it 
suddenly is a list, then this breaks the AT.

Note that just exposing the popup doesn't do any good here
anyways by itself, since the popup will have a bunch of CellView
menu items in it.

owen: how is that assumption going to get 'implicitly hardcoded' into
the AT?  The same could be said for anything that someone could
empirically test, and such an assumption would clearly be unsafe.  The
AT doesnt know anything about the backing GTK+ widget, all it gets is
the 'ROLE' from AT-SPI, and the interfaces.  We try to remind the AT
folks not to hard-code things like that into their heuristics
(interface-based heuristics, the more general the better, are preferred).

We would strongly urge apps not to use GtkComboBox until we can expose
its children via AT-SPI - otherwise significant functionality will
regress, particularly for GOK users.  I have been testing/exploring
GtkCombo from an at-client point of view and it is a very serious
regression from GtkOptionMenu indeed.

I would note at this point that I wrote the GOK code which interacts
with comboboxes of all kinds.  It makes no assumptions about the
children of comboboxes except the following:

* editable comboboxes are expected to have a descendant somewhere that
implements (Atk)EditableText; [if they don't nothing blows up, but
the user cannot easily enter text in the combo via the AT]

* comboboxes have, somewhere inside them, a container whose children
are ROLE_LISITEM or ROLE_MENUITEM, or which implements AtkTable.

I believe that the above pretty much covers the bases.  But at the
moment I cannot do anything with GtkComboboxes at (in GOK).

If 2.4.1 is feasible for gnome 2.6 RC then that would of course be
fine.  With Padraig ready to assist; I sure hope so.  

Bill, I believe any action at this point has to come from your side,
we hardly have time to fix the more embarrassing combobox bugs which
don't require a disability to be seen. 
Since we will not add any more API between Monday and 2.4, any work on
this will have to happen inside gtk. The plan would be roughly the
following:

- take the gail accessible implementations for gtkoptionmenu and 
  gtkcombo
- merge them somehow, so that the right thing happens depending on
  the style of the gtkcombobox
- dump it into gtk, adjust it for gtkcombobox
- see if that gives you a reasonable a11y implementation for 
  GtkComboBoxEntry in both styles
- GtkComboBox will still suffer from the non-accessability of the
  cell view.  

Matthias:

Adding the _single_ API call for getting the popup object would still,
in my opinion, be the best solution for 2.4.X; it would require much
less gtk+ code and the gail implementation code would not have to
change very much.

Introducing such accessibility regressions with new gtk+ widgets is
not good, we should aim to make sure it doesn't happen in the future.
 The minumum requirement for GtkCombo accessibility is API with which
gail can obtain the child widgets from gtk+; gail won't need to make
assumptions about their type or role however.

If you add such API then we (a11y team) can fix this for gnome 2.6, in
all likelihood.  It seems that fixing this without the simple new
piece of api (similar to Padraig's proposals) would be much harder to
do in time and require a lot more of the gtk+ team's time.

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

Created attachment 25389 [details] [review]
Proposed patch

The propsoed patch will allow me to complete acessibility support for
GtkCombo, except for the problem with GtkCellViewMenuItem which is bug
#136637.

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

Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as
Matthias said he was trying to do himself on IRC and was asking for help with. 
If you see this message, it means I was successful at fixing the borken-ness in
bugzilla :)  Sorry for the spam; just query on this message and delete all
emails you get with this message, since there will probably be a lot.

I've added gtk_combo_box_get_popup_accessible() to cvs HEAD now.