After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 342420 - [a11y]: Orca not correctly reporting key values in gconf-editor
[a11y]: Orca not correctly reporting key values in gconf-editor
Status: RESOLVED WONTFIX
Product: gconf-editor
Classification: Applications
Component: general
2.14.x
Other All
: Normal normal
: ---
Assigned To: Gconf Editor Maintainers
Gconf Editor Maintainers
gnome[unmaintained]
: 620152 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-05-20 15:13 UTC by Rich Burridge
Modified: 2018-07-01 08:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Debug output from Orca while doing the describing steps. (113.69 KB, text/plain)
2006-05-20 15:14 UTC, Rich Burridge
  Details
Patch adding name/description to name/value TreeView (1.76 KB, patch)
2006-07-27 18:02 UTC, Fernando Herrera
none Details | Review
Patch creating value column in the same way than name column (1.58 KB, patch)
2006-07-27 19:20 UTC, Fernando Herrera
none Details | Review

Description Rich Burridge 2006-05-20 15:13:52 UTC
Please describe the problem:
The gconf-editor uses a table of name/value pairs 
for each set of gconf resources. Those Name/Value pairs are
in a table where each row in the table contains two table cells
(the Name and Value). The first table cell (the Name) consists
of two other table cells (a small image and the text naqming
the gconf resource).

Orca is not correctly reporting the value information.



Steps to reproduce:
1. Start up Orca. Startup gconf-editor
2. Tab to the table of name/value pairs.
3. Move around in the table with the arrow keys.


Actual results:
Nothing is spoken for the value table cells.

Expected results:
Orca should be reporting back on the contents of the value cells.

Does this happen every time?
Yes.

Other information:
I will be attaching a debug.out created when testing this.
Comment 1 Rich Burridge 2006-05-20 15:14:51 UTC
Created attachment 65903 [details]
Debug output from Orca while doing the describing steps.
Comment 2 Willie Walker 2006-05-22 14:22:50 UTC
When looking at gconf-editor in at-poke, it looks as though the cells for holding the value have very little accessible information associated with them whatsoever:

No name
No description
No accessible text
No specializations
...

Without any information about what is in the cell, Orca cannot present anything useful to the user.  :-(  My thought would be that this is either a gconf-editor bug or a gail/gtk table bug.
Comment 3 Rich Burridge 2006-07-26 20:50:35 UTC
Transferring to gconf-editor for further evaluation.
Comment 4 Fernando Herrera 2006-07-27 09:45:16 UTC
Humm, this is really weird. gconf-editor has two "big" widget on the right panel:
- A ScrollWindow with a GtkTreeView for the NAME/VALUE information
- A GtkTable for Key Documentation.

however at-poke recognize the GtkTreeView as a GtkTable. 

Maybe gconf-editor is adding these widgets in some crazy way that confuses at, or maybe it's a strange bug on at. I'll take a look
Comment 5 Fernando Herrera 2006-07-27 09:58:24 UTC
This is happening in both treeviews and I don't know why.

Does seting the atk role by hand in gconf-editor make it read by orca?

Adding these two lines to gconf_editor_window_init function in gconf-editor-window.c:

        AtkObject *ao = gtk_widget_get_accessible (window->list_view);
        atk_object_set_role (ao, ATK_ROLE_TREE_TABLE);
Comment 6 Rich Burridge 2006-07-27 16:56:19 UTC
I applied the following change to the version of gconf-editor in CVS HEAD:

Index: gconf-editor-window.c
===================================================================
RCS file: /cvs/gnome/gconf-editor/src/gconf-editor-window.c,v
retrieving revision 1.95
diff -u -r1.95 gconf-editor-window.c
--- gconf-editor-window.c       9 May 2006 05:32:47 -0000       1.95
+++ gconf-editor-window.c       27 Jul 2006 16:53:33 -0000
@@ -1555,7 +1555,9 @@
        window->list_model = gconf_list_model_new ();
        window->sorted_list_model = gtk_tree_model_sort_new_with_model (window->list_model);
        window->list_view = gtk_tree_view_new_with_model (window->sorted_list_model);
-       g_object_unref (G_OBJECT (window->list_model));
+       AtkObject *ao = gtk_widget_get_accessible (window->list_view);
+        atk_object_set_role (ao, ATK_ROLE_TREE_TABLE);
+        g_object_unref (G_OBJECT (window->list_model));
        g_object_unref (G_OBJECT (window->sorted_list_model));

        gtk_tree_sortable_set_sort_column_id (GTK_TREE_SORTABLE (window->sorted_list_model),

I then reran Orca. Whereas the role of that "table" is now showing
up as "tree table" (as opposed to just "table"), Orca is still unable
to read anything from the table cells in the second column.

What you probably need to do is set an accessible name or description
for thos table cells.
Comment 7 Fernando Herrera 2006-07-27 18:02:21 UTC
Created attachment 69751 [details] [review]
Patch adding name/description to name/value TreeView

Something like this works? (Sorry I don't have a copy of orca neither gnopernicus here and I am connecting via GPRS)
Comment 8 Rich Burridge 2006-07-27 18:54:26 UTC
From a cursory look at the patch, I don't think this is going
to help. It's the table cells within the table that are the problem,
not the actual table or the column headers.

For example, I bring up gconf-editor. I click on the little
arrow to the left of the "GNOME" entry in the tree table on the left,
to expand it. I then select Spell. When I do that the table on
the right with column headers of Name and Value, gets filled with
about seven rows of items. The items in the second column (the values)
are the ones that aren't accessible. Those table cells are the ones
where you need to add an accessible name (to each one) which is the
value. 

I'm not familiar enough with the gconf-editor source to tell you exactly
where this is.
Comment 9 Fernando Herrera 2006-07-27 19:05:19 UTC
Well, they are not cells inside a table, they are elements in the GtkListModel that are showed dynamically on the GtkTreeView, anyway I'll play a little bit with it to check what it wrong, because GtkTreeView elements should be accesible.
Comment 10 Fernando Herrera 2006-07-27 19:19:11 UTC
The difference between name column (that is read ok) and value colunm is that the first one is composed step by step for adding two cell renderers (pixbuf + text). The value one is created and appended with a gtk convenience funcion (create column+celltextrenderer). Maybe there is something wrong there.

Can you try this patch on a clean gconf-editor?

Comment 11 Fernando Herrera 2006-07-27 19:20:52 UTC
Created attachment 69759 [details] [review]
Patch creating value column in the same way than name column
Comment 12 Rich Burridge 2006-07-27 20:28:59 UTC
I tried this last patch on a clean checkout of gconf-editor
from CVS HEAD. Now I'm finding that there is nothing displayed at
all in the second column of the Name/Value table (including nothing
in the column heading). This is irrespective of whether Orca is 
running or not.

This is with GNOME 2.14 on Solaris x86.

Fernando, I suggest we get you to the point where you can run Orca
against gconf-editor for yourself, so you can try these things out.

You should be able to find instructions on how to set this up at:

http://live.gnome.org/Orca/

(see section 4).

If you have any problems setting Orca up, please let me know.

Thanks.
Comment 13 Fernando Herrera 2006-07-28 15:02:52 UTC
Ok, I found the problem. The Value Column is using a custom cell renderer:
gconf_cell_renderer_new
that is not accesible at all. I'll take a look on it.
Comment 14 Rich Burridge 2007-01-04 21:25:01 UTC
I started looking at this, this morning. From SVN trunk, I tried the
following change:

Index: gconf-cell-renderer.c
===================================================================
--- gconf-cell-renderer.c       (revision 1199)
+++ gconf-cell-renderer.c       (working copy)
@@ -136,6 +136,7 @@
 gconf_cell_renderer_get_size (GtkCellRenderer *cell, GtkWidget *widget, GdkRectangle *cell_area,
                              gint *x_offset, gint *y_offset, gint *width, gint *height)
 {
+       AtkObject *ao = NULL;
        GConfCellRenderer *cellvalue;
        gchar *tmp_str;

@@ -208,6 +209,22 @@
                g_print ("get_size: Unknown type: %d\n", cellvalue->value->type);
                break;
        }
+
+        /* Set the accessible name for this cell. */
+        gint bool_val;
+        gchar *acc_value;
+
+        ao = gtk_widget_get_accessible (widget);
+        if (cellvalue->value->type == GCONF_VALUE_BOOL) {
+            bool_val = gconf_value_get_bool (cellvalue->value);
+            acc_value = g_strdup( (bool_val) ? "true" : "false");
+        } else {
+            g_object_get (G_OBJECT (cellvalue->text_renderer),
+                                    "text", &acc_value,
+                                    NULL);
+        }
+        atk_object_set_name (ao, acc_value);
+        g_free (acc_value);
 }

 static void

What I was hoping here was that when you called the gconf_cell_render_get_size
routine, that the value of "widget" would be a unique GtkWidget for each
GtkCellRenderer call, and from that you would be able to set the accessible
name for each of the cells in the "value" column. What it appears to be
is the over-arching table.

My knowledge of GtkCellRenderer's is minimal. If there is a way to get 
the individual table cell's from within that routine, please let me know 
and I'll try again.
Comment 15 Javier 2007-09-21 07:23:31 UTC
Last couple days I have been looking into this and doesn't appears there is a good solution here.
I have read following from a gtk cell renderer:
"". These objects are used primarily by the 
GtkTreeView
 widget, though they aren't tied to them in any specific way. It is worth noting that 
GtkCellRenderer
 is not a 
GtkWidget
 and cannot be treated as such. 
The primary use of a 
GtkCellRenderer
 is for drawing a certain graphical elements on a 
GdkDrawable
. Typically, one cell renderer is used to draw many cells on the screen. To this extent, it isn't expected that a CellRenderer keep any permanent state
around. Instead, any state is set just prior to use using 
GObject
s property system. Then, the cell is measured using 
gtk_cell_renderer_get_size()
. Finally, the cell is rendered in the correct location using 
gtk_cell_renderer_render()." 

Would be possible that in this case gconf-editor could use table_cells within that table where gtk_cell_renderers are painted?
Gconf values are true/false (checkboxes), text strings, or int values. I think table cells can manage these type of widgets.
Also, I don't know at the moment if you can render gtk_cell_renderers within a table cell?
So We can add table_cells to this table and render the gtk_cells_renderer within these and give it the accessible name of value content.
 
Comment 16 André Klapper 2011-12-17 10:18:31 UTC
*** Bug 620152 has been marked as a duplicate of this bug. ***
Comment 17 André Klapper 2018-07-01 08:39:46 UTC
gconf-editor is not under active development anymore and has not seen code changes for six years. 
Its codebase has been archived: https://gitlab.gnome.org/Archive/gconf-editor/commits/master

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.