GNOME Bugzilla – Bug 583597
Accessible table interface broken for Contacts list
Last modified: 2020-06-06 16:31:07 UTC
Steps to reproduce: 1. Launch Ekiga with no "Neighbours" present. 2. Launch Accerciser. In Accerciser's tree of accessibles (left-hand pane) select the accessible of ROLE_TABLE which corresponds to Ekiga's Contacts list. 3. In Accerciser's IPython Console, type: table = acc.queryTable() for i in range(table.nRows): print table.getIndexAt(i, 0), table.getAccessibleAt(i, 0).getIndexInParent() 4. On a different computer, sign on to Ekiga so that the Neighbour node gets populated. 5. On the original computer, expand the Neighbours node to show the neighbor (if it is not already expanded). 6. Re-print the table row information from step 3. Expected results: 1. The two indices printed for each row would be the same. 2. The indices for any given row would not repeat those of other rows. Actual results (Step 3): 1. The two indices printed for each row are the same, BUT 2. The indices associated with the unpopulated "Neighbours" node are a repeat of those for the row "Local roster" node. Example: 3 3 <------ Local roster 7 7 11 11 13 13 9 9 15 15 3 3 <------ Neighbours Actual results (Step 6): 1. The indices printed for each row are not always the same, AND 2. All rows related to "Neighbours" share the same indices as the "Local roster" node. Example: 3 3 7 7 13 11 ? 15 13 ? 9 9 17 15 ? 3 3 <------ Neighbours (row serving as section indicator) 3 3 <------ Neighbours (1/1) 3 3 <------ Jane Doe The impact of this bug is that when a user is arrowing about his/her Contacts list, all of the "Neighbours" rows are spoken and brailled as "Local roster". I can reproduce this in OpenSolaris 2009.06 - build 111a (Ekiga 3.0.1) and Ubuntu Jaunty (Ekiga 3.2.0).
I have no clue what you're talking about... the local roster and the neighbours appear in the same widget using the same code : how could it be broken for one and not the other!?
And I'm afraid I don't know how to make applications accessible when they are using non-standard widgets; I know how to make Orca provide access to accessible widgets. :-) Therefore I'm adding Li Yuan to the CC list because he knows how to do both. :-) Hopefully he can provide the needed info.
Is contacts list a standard Gtk+ widget or custom widget?
It's a widget built with a GtkTreeView, but we do use a special cell renderer, see: http://git.gnome.org/cgit/ekiga/tree/lib/gui/gm-cell-renderer-bitext.c But as I already asked : the local roster and the neighbours appear in the same widget using the same code : how could it be broken for one and not the other!?
(In reply to comment #4) > It's a widget built with a GtkTreeView, but we do use a special cell renderer, > see: http://git.gnome.org/cgit/ekiga/tree/lib/gui/gm-cell-renderer-bitext.c > For a special cell renderer, we need an a11y implementation. > But as I already asked : the local roster and the neighbours appear in the same > widget using the same code : how could it be broken for one and not the other!? > Does tree model emit "row-inserted" during step 4?
I don't know how to provide "an a11y implementation" for the cell renderer -- could you give hints? The tree model is nothing fancy, and as I told several time, the same code path is used to add all presence information to the gui, so I can't see how things could be broken for the avahi presentities and not the the local roster!
(In reply to comment #6) > I don't know how to provide "an a11y implementation" for the cell renderer -- > could you give hints? Li - can you point Snark in the right direction, please? :-)
(In reply to comment #6) > I don't know how to provide "an a11y implementation" for the cell renderer -- > could you give hints? > > The tree model is nothing fancy, and as I told several time, the same code path > is used to add all presence information to the gui, so I can't see how things > could be broken for the avahi presentities and not the the local roster! Just refer to cellrenderer code in gail, e.g. gailtextcell.c. If its major function is render text, the a11y implementation needs to implement update_cache (in GAIL_RENDERER_CELL_CLASS)and get_name (in ATK_OBJECT_CLASS) at least.
I finally found the time to have a look at what you explained, and read gailtextcell.c ; from what I understand : (1) get_name only returns the text in the cell -- we have two texts, should we concatenate both g_strdup_printf ("%s %s", first, second); ? I guess in that case we'll have to cache that for memory management purpose... (2) update_cache... uh... I didn't get what it was doing exactly... it's emitting various signals, but it's not clear what I'm supposed to do...
Hm. Any news on this issue?
(In reply to comment #9) > I finally found the time to have a look at what you explained, and read > gailtextcell.c ; from what I understand : > (1) get_name only returns the text in the cell -- we have two texts, should we > concatenate both g_strdup_printf ("%s %s", first, second); ? I guess in that > case we'll have to cache that for memory management purpose... This depends on what you want to output to the users. Just find the best way to express the content of the two texts should be OK. > (2) update_cache... uh... I didn't get what it was doing exactly... it's > emitting various signals, but it's not clear what I'm supposed to do... update_cache is called when the cell's value maybe changed, gailtreeview.c calls this function. Basically compare the value you cached to the current value, if there is any change, send out a signal.
(In reply to comment #0) > Steps to reproduce: > > 1. Launch Ekiga with no "Neighbours" present. > > 2. Launch Accerciser. In Accerciser's tree of accessibles (left-hand pane) > select the accessible of ROLE_TABLE which corresponds to Ekiga's Contacts list. > > 3. In Accerciser's IPython Console, type: > > table = acc.queryTable() > for i in range(table.nRows): > print table.getIndexAt(i, 0), table.getAccessibleAt(i, > 0).getIndexInParent() > > 4. On a different computer, sign on to Ekiga so that the Neighbour node gets > populated. > > 5. On the original computer, expand the Neighbours node to show the neighbor > (if it is not already expanded). > > 6. Re-print the table row information from step 3. > > Expected results: > > 1. The two indices printed for each row would be the same. > > 2. The indices for any given row would not repeat those of other rows. > > Actual results (Step 3): > > 1. The two indices printed for each row are the same, BUT > > 2. The indices associated with the unpopulated "Neighbours" node are a repeat > of those for the row "Local roster" node. > > Example: > > 3 3 <------ Local roster > 7 7 > 11 11 > 13 13 > 9 9 > 15 15 > 3 3 <------ Neighbours > > Actual results (Step 6): > > 1. The indices printed for each row are not always the same, AND > > 2. All rows related to "Neighbours" share the same indices as the "Local > roster" node. > > Example: > > 3 3 > 7 7 > 13 11 ? > 15 13 ? > 9 9 > 17 15 ? > 3 3 <------ Neighbours (row serving as section indicator) > 3 3 <------ Neighbours (1/1) > 3 3 <------ Jane Doe > > The impact of this bug is that when a user is arrowing about his/her Contacts > list, all of the "Neighbours" rows are spoken and brailled as "Local roster". > > I can reproduce this in OpenSolaris 2009.06 - build 111a (Ekiga 3.0.1) and > Ubuntu Jaunty (Ekiga 3.2.0). (In reply to comment #0) > Steps to reproduce: > > 1. Launch Ekiga with no "Neighbours" present. > > 2. Launch Accerciser. In Accerciser's tree of accessibles (left-hand pane) > select the accessible of ROLE_TABLE which corresponds to Ekiga's Contacts list. > > 3. In Accerciser's IPython Console, type: > > table = acc.queryTable() > for i in range(table.nRows): > print table.getIndexAt(i, 0), table.getAccessibleAt(i, > 0).getIndexInParent() > > 4. On a different computer, sign on to Ekiga so that the Neighbour node gets > populated. > > 5. On the original computer, expand the Neighbours node to show the neighbor > (if it is not already expanded). > > 6. Re-print the table row information from step 3. > > Expected results: > > 1. The two indices printed for each row would be the same. > > 2. The indices for any given row would not repeat those of other rows. > > Actual results (Step 3): > > 1. The two indices printed for each row are the same, BUT > > 2. The indices associated with the unpopulated "Neighbours" node are a repeat > of those for the row "Local roster" node. > > Example: > > 3 3 <------ Local roster > 7 7 > 11 11 > 13 13 > 9 9 > 15 15 > 3 3 <------ Neighbours > > Actual results (Step 6): > > 1. The indices printed for each row are not always the same, AND > > 2. All rows related to "Neighbours" share the same indices as the "Local > roster" node. > > Example: > > 3 3 > 7 7 > 13 11 ? > 15 13 ? > 9 9 > 17 15 ? > 3 3 <------ Neighbours (row serving as section indicator) > 3 3 <------ Neighbours (1/1) > 3 3 <------ Jane Doe > > The impact of this bug is that when a user is arrowing about his/her Contacts > list, all of the "Neighbours" rows are spoken and brailled as "Local roster". > > I can reproduce this in OpenSolaris 2009.06 - build 111a (Ekiga 3.0.1) and > Ubuntu Jaunty (Ekiga 3.2.0). In the latest version of Egika, the python script no longer works. I am looking in to the problem and hope rewrite the script. Chip
*** Bug 583013 has been marked as a duplicate of this bug. ***
Ekiga is not under active development anymore: https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/273 Ekiga saw its last release 7 years ago. The last code commits were 4 years ago. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (and transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active Ekiga development again in the future.