I think fixing this is going to be dependent upon implementing
bug #395548 (Refactor calls to util.py as calls from delegates 
in default.py), because the change to the structure of the buddy
list will probably require us to cons up a special version of
[default,util].getNodeLevel().

While I'm waiting for Ubuntu to generate a working update-manager for
Feisty so that I can continue to investigate bug #400763, I thought I'd
take another look at this one.

The problem is that with gaim 2.0.0 beta5, when we call util.getNodeLevel(),
with the obj being a table cell in the buddy list, the obj.relations list
has a length of 0, so that routine always returns -1.

With gaim 2.0.0 beta1, when we call util.getNodeLevel(), with the obj being 
a table cell in the buddy list, the obj.relations list has a length of 1,
and one of the relations is atspi.Accessibility.RELATION_NODE_CHILD_OF,
allowing us to generating a valid node level.

What we need to determine now is why obj.relations is getting set to a
zero length list.

Well, I can get Orca to nicely speak the tree level again with gaim 2.0.0beta6,
if I make the following change to gail/gailtreeview.c:

Index: gailtreeview.c
===================================================================
--- gailtreeview.c      (revision 1239)
+++ gailtreeview.c      (working copy)
@@ -1021,7 +1021,7 @@
   if (container)
     child =  ATK_OBJECT (container);

-  if (expander_tv == tv_col)
+/*  if (expander_tv == tv_col) */
     {
       AtkRelationSet *relation_set;
       AtkObject *accessible_array[1];

What this is doing is going ahead and setting an ATK_RELATION_NODE_CHILD_OF
relationship irrespective of whether the current table cell is in the same
column as the expander cell. Here's more code context so you get the idea
of what's going on:


/*  if (expander_tv == tv_col) */
    {
      AtkRelationSet *relation_set;
      AtkObject *accessible_array[1];
      AtkRelation* relation;
      AtkObject *parent_node;

      relation_set = atk_object_ref_relation_set (ATK_OBJECT (child));

      gtk_tree_path_up (path);
      if (gtk_tree_path_get_depth (path) == 0)
        parent_node = obj;
      else
        {
          gint parent_index;
          gint n_columns;

          n_columns = get_n_actual_columns (tree_view);
          parent_index = get_index (tree_view, path, i % n_columns);
          parent_node = atk_object_ref_accessible_child (obj, parent_index);
        }
      accessible_array[0] = parent_node;
      relation = atk_relation_new (accessible_array, 1,
                                   ATK_RELATION_NODE_CHILD_OF);
      atk_relation_set_add (relation_set, relation);
      g_object_unref (relation);
      g_object_unref (relation_set);
    }

It would seem to be that you should do this for all the children table cells,
but I admit I don't understand this code fully yet.

Is it about time we filed a bug on gail for this?

Transferring to the atk/gail developers for further investigation.
I'll also open an Orca bug so that we can keep track of it.
Add yourself to the cc: if you want up-to-the-minute updates
on this bug!

I don't think we should set the relationship to every columns. Only the expander column should have this relation.
For gaim, it should call gtk_tree_view_set_expander_column to set the correct expander column.
Probably gaim's bug. (because it works before gaim changed its treeview).

Okay. That seems reasonable. Could you recategorize it please? 
It would be nice to try to get this resolved before GNOME 2.18 
final. 

Thanks!

I think I should file a new bug on sourceforge? I will talk with our gaim guy about this.

(In reply to comment #7)
> I think I should file a new bug on sourceforge? I will talk with our gaim guy
> about this.

Li - what did your gaim guy have to say?

Li, I took a look at the pidgin source.  In gtkblist.c, pidgin_blist_show() they do call gtk_tree_view_set_expander_column.  Unfortunately -- assuming I'm reading the code correctly -- it seems that they are setting it to the first column which is hidden and also doesn't contain the expander.  If I remove that call or place it in the column that actually contains the expander, everything is fixed from an accessibility point of view.  Unfortunately, the buddy list shows two expander icons rather than just one.  I tried various and sundry other things and always wound up with two expander icons.  Based on this, my suspicion is that their use of gtk_tree_view_set_expander_column was done quite intentionally to solve this problem.  It just happens to introduce new problems for us.  :-( So is it a gaim/pidgin bug?  It would seem so. But here are my concerns:

1.  If what they did was indeed absolutely necessary to achieve the effect they wanted, they will not be all that receptive to changing it in the spirit of accessibility.   Is there some clever atk call they could do to solve our problem without breaking their look and feel?  If so, and we could point it out to them, that might make them more willing to make the change.

2. What if other application developers do something similar?   We'll be in the same boat of having to convince them to do whatever atk magic that I hope exists. :-)  Rich's solution in comment 3 makes the problem go away, but as you point out we don't want to set the relation for every column.  So I'm wondering, could gail do a check to see if the expander column is not the one that actually contains the expander and, if that's the case, set the relation based on the column that actually does contain the expander?

Hi Joanie, Sorry for reply so late.

(In reply to comment #9)
> Li, I took a look at the pidgin source.  In gtkblist.c, pidgin_blist_show()
> they do call gtk_tree_view_set_expander_column.  Unfortunately -- assuming I'm
> reading the code correctly -- it seems that they are setting it to the first
> column which is hidden and also doesn't contain the expander.  If I remove that
> call or place it in the column that actually contains the expander, everything
> is fixed from an accessibility point of view.  Unfortunately, the buddy list
> shows two expander icons rather than just one.  I tried various and sundry
> other things and always wound up with two expander icons.  

This is weird, sounds like a gtk+ bug? Or Gaim is doing something really special? I will ask rick.ju@sun.com who is working Gaim/Pidgin.

> 1.  If what they did was indeed absolutely necessary to achieve the effect they
> wanted, they will not be all that receptive to changing it in the spirit of
> accessibility.   Is there some clever atk call they could do to solve our
> problem without breaking their look and feel?  If so, and we could point it out
> to them, that might make them more willing to make the change.

I'm not sure. There is no relation between tow columns in the GUI. Add the relation 
to all columns can fix the problem, but it is not a smart way.

> 2. What if other application developers do something similar?   We'll be in the
> same boat of having to convince them to do whatever atk magic that I hope
> exists. :-)  Rich's solution in comment 3 makes the problem go away, but as you
> point out we don't want to set the relation for every column.  So I'm
> wondering, could gail do a check to see if the expander column is not the one
> that actually contains the expander and, if that's the case, set the relation
> based on the column that actually does contain the expander?

En... let me take a look at gtk+'s code.

I will also ask Yi to look at this.

OK, I think Gaim doesn't want to let gtk+ draw the expander for it. It want to draw by itself. There are two kinds of expanders in Gaim, one is for group, another is for contact. I think Gaim want to make the two expanders look same, so it just draw them by itself. But I still don't have any idea about finding the real column that contains the expander.

Can the solution to bug 474504 solve this issue as well??

please see http://bugzilla.gnome.org/show_bug.cgi?id=474504#c3

Just a ping to see where this bug stands.  Thanks!

Please refer to http://bugzilla.gnome.org/show_bug.cgi?id=474504#c7

And also http://bugzilla.gnome.org/show_bug.cgi?id=407647#c2

If you combine the two patches, we seem to be doing the right thing.  Yea! :-)

See bug 474504, the patch should fix this bug.