GNOME Bugzilla – Bug 171232
font preferences: table reporting errors
Last modified: 2005-05-19 08:08:01 UTC
Distribution/Version: JDS Rel3 B31 Using gnopernicus 0.10.4 - With gnopernicus activated and speech enabled, go to Preferences->Desktop Preferences->Display->Fonts - Select the "Application font" button . - Navigate to the "Style" table. - Navigate back to the "Family" table. Notice that speech reports the style table and its current selection, as well as the current family selection for every element in the family table. Example: <shift>+<tab> "Table Family, Schumacher Clean, Table line, Schumacher Clean" <down> "Table Style, Regular, Table Line, Serif" <up> "Table Style, Regular, Table Line, Schumacher Clean" This would be very confusing for the gnopernicus speech user. Also note that when navigating to the table it would be better to report: "Table Family, Table line, Schumacher Clean" rather than: "Table Family, Schumacher Clean, Table line, Schumacher Clean"
this looks to me as though it's caused by 'focus' events from the 'Style' table when changing selections in the Family table.
I do not receive the same output : <shift>+<tab> "Table Family, Schumacher Clean, Table line, Schumacher Clean" <down> "Table Style, Regular, Table Family, Serif, Table Line, Serif" <up> "Table Style, Regular, Table Family, Schumacher Clean,Table Line, Schumacher Clean"
Ada: however you see that your output is still 'wrong', because it includes information from both tables... when I run this I see 'flickering' in the tables as they are re-filled - for instance, each time you change 'family', the 'Style' table has to be re-set to include only the styles which are available for that font family. So I am speculating that we may be getting a focus event from 'Style' along with the event from 'Family'. I haven't confirmed this with event-listener-test however.
In this case, both tables are firing active-descendant-changed events. Gnopernicus converts those events in focus event without checking if the new active child is focused (the problem in gnopernicus). But, both active children have FOCUSED state (the gail problem).
Created attachment 39131 [details] [review] proposed patch This patch checks if the table which has fired the active-descendant-changed event has FOCUSED state. The right solution is to check this for the new active descendant. Because in this case this is always FOCUSED, the check for parent is an workaround to solve the problem.
*** Bug 168241 has been marked as a duplicate of this bug. ***
In case of tables, more than 1 object can have FOCUSED state in same time. For the table which has the keyboard input, the current selected cell and table itself have this state and the other table has a cell which also contains this state. Is this behavior/situation OK?
multiple objects having FOCUSSED state at once seems very suspicious to me. I personally doubt that this is what we really want.
This bug depends on bug #172087
With patch for bug #172087, this bug is no longer present.
Remus - if we set/add ATK_STATE_ACTIVE on the cells instead of ATK_STATE_FOCUSSED, we can avoid the situation in comment #7 where there are multiple objects with ATK_STATE_FOCUSSED. This seems more consistent to me, and it would help GTK+/GNOME be consistent with the info reported by the java-access-bridge.
As Bill states, this is similar to the Java behavior. So please instead use the patch to <a href="http://bugzilla.gnome.org/show_bug.cgi?id=171865">bug #171865</a> for testing. Please confirm if that fixes this bug as well.
The patch from bug #171865 doesn't fix this bug.
Is a revised patch to bug 172087 appropriate here?
Created attachment 39800 [details] [review] Proposed patch for gnopernicus This patch checks if the state object is ACTIVE, before converting the 'active-descendant-changed' event into a "gnopernicus focus" event. The result is that the 'active-descendant-changed' event will be reported by gnopernicus only if the object has the ACTIVE state. An revised patch was added for bug #172087.
Created attachment 46479 [details] [review] Proposed patch
If I understand the patch correctly, the key to not speaking all the extra verbiage is to not change the type of the event to FOCUS, and so only the info about the active descendent itself is spoken. If this tests out OK, I'm happy with this nice and tiny patch!
Gnopernicus doesn't present to user active-descendant-changed event. But, most of them are converted to focus events (if they have a focused ancestor).
Ah, I understand now. You are in fact getting two events and this code ignores one of them in many circumstances. OK, I'm fine with this patch.
Patch committed to CVS head.