GNOME Bugzilla – Bug 499835
No "object:state-changed:selected" event when [un]selecting icon in layered pane.
Last modified: 2011-02-04 16:11:04 UTC
See also Orca bug #486908 which is affected by this problem. Steps to reproduce: 1/ Start Orca. 2/ Start gtk-demo (Icon View->Icon View Basics). 3/ Press Down arrow to move focus to the first icon ("bin"). The "bin" icon is selected. 4/ Press Control-Space The "bin" icon is no longer selected, but is surrounded by the dotted rectangle. When Control-Space is pressed, we do not get any events.
After pressing control-space, the icon is no longer highlighted, but it is still selected, press "space" or "enter" will still work. What kind of event is expected in this situation?
See comment #15 of big #486908 from Will: ...I'd expect to see appropriate "object:state-changed:selected" events for things that were selected and unselected as the result of pressing Ctrl+Space. ...
OK, from the definition of STATE_SELECTED, it is reasonable to remove STATE_SELECTED and emit the event when Ctrl+Space is pressed. I will work on it.
(In reply to comment #3) > OK, from the definition of STATE_SELECTED, it is reasonable to remove > STATE_SELECTED and emit the event when Ctrl+Space is pressed. I will work on > it. > Thanks Li!
GtkIconView emit "toggle_cursor_item" signal when Ctrl+Space, and the default signal handler gtk_icon_view_real_toggle_cursor_item highlight/un-highlight the icon. We can connect to "toggle_cursor_item" to add/remove the STATE_SELECTED state and emit "object:state-changed:selected".
Created attachment 103319 [details] [review] emit the signal of "object:state-changed:selected" to Orca When pressing control-space, gtk_icon_view_real_toggle_cursor_item will emit the signal "object:state-changed:selected", which can be monitored by Event Monitor of Accerciser.
By the way, when we press Right arrow to move focus from one icon(for example, "bin") to another ("boot"), no event will be monitored by Event Monitor of Accerciser. Is it necessary for us to make some modifications in order to emit "object:state-changed:focused" event and "object:state-changed:selected" event? Could you please give us some suggestion? Thank you very much!
> By the way, when we press Right arrow to move focus from one icon(for example, > "bin") to another ("boot"), no event will be monitored by Event Monitor of > Accerciser. Is it necessary for us to make some modifications in order to emit > "object:state-changed:focused" event and "object:state-changed:selected" event? > > Could you please give us some suggestion? Thank you very much! I let Will give you the definitive answer, but my take on it is, yes, we will need those events to fix Orca bug #486908. Thanks for the patch! I'll test it tomorrow when I return to work.
(In reply to comment #7) > By the way, when we press Right arrow to move focus from one icon(for example, > "bin") to another ("boot"), no event will be monitored by Event Monitor of > Accerciser. Is it necessary for us to make some modifications in order to emit > "object:state-changed:focused" event and "object:state-changed:selected" event? In order for Orca to provide feedback to the user, it definitely needs events telling it what is going on. So, if the focus and selection state are changing, events corresponding to those changes should be emitted. Thanks! BTW, please also make sure any fixes for these issues go into trunk as well as the stuff being used to generate the GNOME 2.22 release. I'm not sure where things stand for GAIL/GTK+ for GNOME 2.22 and trunk, so that leads to my confusion. :-( Do you know what branches of gail and gtk+ are being used for the GNOME 2.22 release?
I had to upgrade one of my Ubuntu machines to Hardy to test this. I also installed Gtk+ v2.12.5 and applied the patch to that. We are now getting the following two events when you type Control-Space to deselect the "bin" icon. I do not see any "object:state-changed:selected" events. vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv OBJECT EVENT: object:state-changed:focused detail=(0,0) app.name='gtk-demo' name='bin' role='icon' state='enabled focusable focused selectable sensitive showing visible' relations='' Finding top-level object for source.name=bin --> obj.name= --> obj.name= --> obj.name= --> obj.name=GtkIconView demo ^^^^^ PROCESS OBJECT EVENT object:state-changed:focused ^^^^^ DEQUEUED EVENT object:state-changed:active <---------- vvvvv PROCESS OBJECT EVENT object:state-changed:active vvvvv OBJECT EVENT: object:state-changed:active detail=(0,0) app.name='gtk-demo' name='GtkIconView demo' role='frame' state='enabled resizable sensitive showing visible' relations='' ^^^^^ PROCESS OBJECT EVENT object:state-changed:active ^^^^^ Orca is unfortunately not speaking anything, but probably Orca bug #486908 needs to be fixed to make that happen. I'll attach a full Orca debug log in a moment.
Created attachment 103468 [details] Orca debug output whilst running this test. I take it back. I'm not seeing any events when running the steps in the description to this bug. Neither when I unselect the "bin" icon or when I then reselect it. I'm only running Gtk+ v2.12.5, not SVN trunk. Should that make a difference?
(In reply to comment #9) > BTW, please also make sure any fixes for these issues go into trunk as well as > the stuff being used to generate the GNOME 2.22 release. I'm not sure where > things stand for GAIL/GTK+ for GNOME 2.22 and trunk, so that leads to my > confusion. :-( Do you know what branches of gail and gtk+ are being used for > the GNOME 2.22 release? > Yes, I always make sure:-) For now, gail trunk will be used for GNOME 2.22. If Matthias want to merge gail into GTK+ 2.12, gail code in GTK+ 2.12 will be used for GNOME 2.22. Anyway, any changes will be commit into both gail and GTK+, so all bug fixes will be released with GNOME 2.22.
(In reply to comment #12) > (In reply to comment #9) > > BTW, please also make sure any fixes for these issues go into trunk as well as > > the stuff being used to generate the GNOME 2.22 release. I'm not sure where > > things stand for GAIL/GTK+ for GNOME 2.22 and trunk, so that leads to my > > confusion. :-( Do you know what branches of gail and gtk+ are being used for > > the GNOME 2.22 release? > > > > Yes, I always make sure:-) For now, gail trunk will be used for GNOME 2.22. If > Matthias want to merge gail into GTK+ 2.12, gail code in GTK+ 2.12 will be used > for GNOME 2.22. Anyway, any changes will be commit into both gail and GTK+, so > all bug fixes will be released with GNOME 2.22. > Thanks Li! You kick butt as usual.
(In reply to comment #11) > Created an attachment (id=103468) [edit] > Orca debug output whilst running this test. > > I take it back. I'm not seeing any events when running the > steps in the description to this bug. Neither when I unselect > the "bin" icon or when I then reselect it. > I am sorry that this patch didn't bring a satisfied result. But with this patch, we could get "object:state-changed:selected" event by Event Monitor of Accerciser. This means that gtk has emitted this event to orca, but unfortunately, Orca gives no response to this event. I am working on it now, and will try to handle it as soon as possible.
> I am sorry that this patch didn't bring a satisfied result. > But with this patch, we could get "object:state-changed:selected" event by > Event Monitor of Accerciser. This means that gtk has emitted this event to > orca, but unfortunately, Orca gives no response to this event. Ack! You are absolutely correct. Li, we will need to add a couple of lines of code in Orca to default.py. Here's the diff against svn trunk: $ svn diff default.py Index: default.py =================================================================== --- default.py (revision 3494) +++ default.py (working copy) @@ -838,6 +838,8 @@ self.onStateChanged listeners["object:state-changed:expanded"] = \ self.onStateChanged + listeners["object:state-changed:selected"] = \ + self.onStateChanged listeners["object:selection-changed"] = \ self.onSelectionChanged listeners["object:property-change:accessible-value"] = \ If you don't beat me to it, I'll retest this tomorrow with your patch and this patch and see if things start to work. If you can also provide a patch for the problem you found in comment #7, I'll be happy to test that too. Thanks!
Sure, Liyan will paste a "big" patch for gtkiconview to fix this bug and problem in comment #7 and bug #501117, with Orca debug output.
Created attachment 103657 [details] Correct Orca output whilst running this test. Sorry about that. When I add the patch to Orca, we now correctly see the new event. For the record, a better Orca patch would probably be: $ svn diff Index: src/orca/default.py =================================================================== --- src/orca/default.py (revision 3495) +++ src/orca/default.py (working copy) @@ -838,6 +838,8 @@ self.onStateChanged listeners["object:state-changed:expanded"] = \ self.onStateChanged + listeners["object:state-changed:selected"] = \ + self.onSelectionChanged listeners["object:selection-changed"] = \ self.onSelectionChanged listeners["object:property-change:accessible-value"] = \ and we can handle fixing this up as part of Orca bug #486908. Thanks!
Created attachment 103665 [details] Another Orca debug output: 'selected' state missing from certain icon events. There is still a problem with the current Gtk+ patch. Try the following: 1/ Start Orca. 2/ Start gtk-demo (Icon View->Icon View Basics). 3/ Press Down arrow to move focus to the first icon ("bin"). The "bin" icon is selected. 4/ Press Control-Space The "bin" icon is no longer selected, but is surrounded by the dotted rectangle. 5/ Press Control-Space The "bin" icon is selected again. From the Orca debug, after step #4 above, we get the following event in Orca (line 339): OBJECT EVENT: object:state-changed:selected detail=(0,0) app.name='gtk-demo' name='bin' role='icon' state='enabled focusable focused selectable sensitive showing visible' relations='' You will see that the state of the icon is not 'selected'. That's correct. From the Orca debug, after step #5 above, we get the following event in Orca (line 393): OBJECT EVENT: object:state-changed:selected detail=(1,0) app.name='gtk-demo' name='bin' role='icon' state='enabled focusable focused selectable sensitive showing visible' relations='' ^^^^^ PROCESS OBJECT EVENT object:state-changed:selected ^^^^^ DEQUEUED EVENT object:selection-changed <---------- vvvvv PROCESS OBJECT EVENT object:selection-changed vvvvv OBJECT EVENT: object:selection-changed detail=(0,0) app.name='gtk-demo' name='None' role='layered pane' state='enabled focusable sensitive showing visible' relations='' again, you will see that the state of the icon is not 'selected'. That is not correct. It also looks like the "focus:" event after pressing Down in step #3 (line 267): OBJECT EVENT: focus: detail=(0,0) app.name='gtk-demo' name='bin' role='icon' state='enabled focusable focused selectable sensitive showing visible' relations='' does not give us a 'selected' state. That too would appear to be incorrect.
Yes, this is because we haven't paste the big patch yet :-) To fix bug #486908 and reduce redundant signals, the patch will be a little more complicate, we are working on it.
> Yes, this is because we haven't paste the big patch yet :-) Ah! Okay, thanks.
Created attachment 103721 [details] [review] patch for bug_499835_501117_486908 In this patch, event "object:state-changed:selected" and state "selected" have been added to IconViewItem. And when press Shift_Right (or other arrow), the corresponding events have been added too. Try the follwing: 1/ Start Orca. 2/ Start gtk-demo (Icon View->Icon View Basics). 3/ Press Down arrow to move focus to the first icon ("bin"). The "bin" icon is selected. 4/ Press Control-Space The "bin" icon is no longer selected, but is surrounded by the dotted rectangle. 5/ Press Control-Space The "bin" icon is selected again. 6/ Press Arrow Right (from "bin" to "boot") 7/ Press shift_Right (from "boot" to "cdrom") And the result is as follows, which is from Orca debug. 4/ press Control_Space ("bin"): OBJECT EVENT: object:state-changed:selected detail=(0,0) app.name='gtk-demo' name='bin' role='icon' state='enabled focusable focused selectable sensitive showing visible' relations='' 5/ press Control_Space another time ("bin") : OBJECT EVENT: object:state-changed:selected detail=(1,0) app.name='gtk-demo' name='bin' role='icon' state='enabled focusable focused selectable selected sensitive showing visible' relations='' 6/ Arrow Right (from "bin" to "boot") OBJECT EVENT: object:state-changed:focused detail=(0,0) app.name='gtk-demo' name='bin' role='icon' state='enabled focusable selectable sensitive showing visible' relations='' OBJECT EVENT: object:state-changed:selected detail=(0,0) app.name='gtk-demo' name='bin' role='icon' state='enabled focusable selectable sensitive showing visible' relations='' OBJECT EVENT: object:state-changed:selected detail=(1,0) app.name='gtk-demo' name='boot' role='icon' state='enabled focusable focused selectable selected sensitive showing visible' relations='' OBJECT EVENT: object:state-changed:focused detail=(1,0) app.name='gtk-demo' name='boot' role='icon' state='enabled focusable focused selectable selected sensitive showing visible' relations='' 7/ shift_right (from "boot" to "cdrom") OBJECT EVENT: object:state-changed:focused detail=(0,0) app.name='gtk-demo' name='boot' role='icon' state='enabled focusable selectable selected sensitive showing visible' relations='' OBJECT EVENT: object:state-changed:focused detail=(1,0) app.name='gtk-demo' name='cdrom' role='icon' state='enabled focusable focused selectable selected sensitive showing visible' relations='' OBJECT EVENT: object:state-changed:selected detail=(1,0) app.name='gtk-demo' name='cdrom' role='icon' state='enabled focusable focused selectable selected sensitive showing visible' relations=''
But there is a confused problem. When press Shift_Right (for example: from "bin" to "boot"), the result is: both two icons are selected, and "focused" is removed from "bin", and at the same time, it is added to "boot". Consequently, when this happens, gtk+ doesn't emit "object:state-changed:selected" for "bin", because this icon is highlighted and selected all the time. I don't know whether it is proper for this case, could you please give me some suggestion? Thanks very much!
Hi LiYan, thanks for the patch. I've tried this in conjunction with the latest patch for Orca to bug #486908: http://bugzilla.gnome.org/attachment.cgi?id=103735 and it seems to nicely work with Control-Space for selecting and unselecting an icon in the gtk-demo (Icon View->Icon View Basics) demo. > But there is a confused problem. When press Shift_Right (for example: from > "bin" to "boot"), the result is: both two icons are selected, and "focused" is > removed from "bin", and at the same time, it is added to "boot". > Consequently, when this happens, gtk+ doesn't emit > "object:state-changed:selected" for "bin", because this icon is highlighted and > selected all the time. > I don't know whether it is proper for this case, could you please give me some > suggestion? I'd like Will to answer this question too, but my understanding from your scenerio above, is that if the "bin" icon is still selected, then there doesn't need to be another "object:state-changed:selected" event, because the 'selected' state of that icon hasn't changed. If that's the case, I'd say this patch fixes the specified problem and can be committed and closed as FIXED.
(In reply to comment #23) > I'd like Will to answer this question too, but my understanding from your > scenerio above, is that if the "bin" icon is still selected, then there > doesn't need to be another "object:state-changed:selected" event, because > the 'selected' state of that icon hasn't changed. Agreed -- if the state doesn't change for an object, a state-changed event shouldn't be emitted for it. So, for the example given, the only state change event emitted should be for the newly selected object. > If that's the case, I'd say this patch fixes the specified problem and can > be committed and closed as FIXED. I agree, and say "THANKS!" to everyone. As a related sanity check: Rich can you make sure an object:selection-changed event is delivered for the layered pane for the various scenarios in question? I'm guessing it probably works, but a separate, lower priority bug, should be opened if it doesn't.
> As a related sanity check: Rich can you make sure an > object:selection-changed event is delivered for the layered > pane for the various scenarios in question? I'm guessing it > probably works, but a separate, lower priority bug, should be > opened if it doesn't. This is how we are now doing the "unselected" / "selected" speech utterances for Control-Space [un]selection of icons in a layered pane. See the second part of: http://bugzilla.gnome.org/attachment.cgi?id=103735 (the latest attachment to orca bug #486908.
(In reply to comment #25) > > As a related sanity check: Rich can you make sure an > > object:selection-changed event is delivered for the layered > > pane for the various scenarios in question? I'm guessing it > > probably works, but a separate, lower priority bug, should be > > opened if it doesn't. > > This is how we are now doing the "unselected" / "selected" speech > utterances for Control-Space [un]selection of icons in a layered > pane. See the second part of: > > http://bugzilla.gnome.org/attachment.cgi?id=103735 > > (the latest attachment to orca bug #486908. > Thanks!
Just one important note. You need both the first and last patch to this bug in order for this to work. I note that you've marked the first patch as obsolete. It's actually still needed as well as the final "three for one" fix. Thanks to Joanie for confirming this. I didn't look too close at the patches status when I tested this on Friday. LiYan, can you please make sure that you check both fixes in. Thanks!
I can also confirm that the two patches combined fix bug 501117 and in doing so cause Orca to automatically do the right thing w.r.t Orca bug 486909. Awesome!!
Ack! That first patch is obsolete after all. Setting it accordingly. The patch to Orca was incorrect. I'm just about to add a new patch to bug #486909 that hopefully works a lot better with the single attachment: http://bugzilla.gnome.org/attachment.cgi?id=103721
(In reply to comment #27) > Just one important note. You need both the first and last patch > to this bug in order for this to work. I note that you've marked > the first patch as obsolete. It's actually still needed as well > as the final "three for one" fix. > > Thanks to Joanie for confirming this. I didn't look too close at > the patches status when I tested this on Friday. > > LiYan, can you please make sure that you check both fixes in. > > Thanks! > Thanks for your suggestion! Yes, the first patch in comment #6 is actually obsolete, and personally I think the final one in comment #21 could fix the three bugs.
LiYan, we've given this last patch a lot of testing with Orca and think it's great. Could you please commit it? Thanks.
Could somebody please check in this patch before the next GNOME release? Thanks.
Sure. It is great that the patch works. Since this is a patch for gtk+, we still need the review from gtk+ maintainers. Just took a look at the patch, I think we may need some modifications (format problems etc.) It is very near chinese spring festival, Liyan has been on vacation since Feb. 1th, I think she will be back in two weeks. I will take vacation from Feb. 6th to Feb. 17th. To make sure the patch can be committed into GNOME 2.22, I will work on the patch during the holiday.
Created attachment 104459 [details] [review] new patch patch waiting for gtk+ maintainers review.
Looking at the patch, I assume gtk_icon_view_item_selected_changed is supposed to be called whenever the selection status of an item changes. If that is the case, it should also be called in gtk_icon_view_select_item gtk_icon_view_unselect_item Looking at this code in gtk_icon_view_select_all_between: if (!item->selected) { dirty = TRUE; gtk_icon_view_item_selected_changed (icon_view, item); } item->selected = TRUE; Note that gtk_icon_view_item_selected_changed is called _before_ setting item->selected to the new value. This is bad, since _selected_changed() is using item->selected.
Created attachment 105010 [details] [review] patch with my proposed corrections Can you tell me if this patch works for you ? I tried to test it, but gtk-demo would segfault inside gail...
Created attachment 105064 [details] Orca debug generated whilst testing latest patch from Matthew > Can you tell me if this patch works for you ? Yes, it works just fine. Tested with the very latest version of Orca in SVN trunk. Line 359 shows the start of processing of an "object:state-changed:selected" for the icon in gtk-demo after Control-Space is pressed. Thanks!
2008-02-12 Matthias Clasen <mclasen@redhat.com> * gtk/gtkiconview.c: Fix state change reporting for accessibility. (#499835, Rich Burridge, patch by LiYan Zhang)
(In reply to comment #38) > 2008-02-12 Matthias Clasen <mclasen@redhat.com> > * gtk/gtkiconview.c: Fix state change reporting for > accessibility. (#499835, Rich Burridge, patch by LiYan Zhang) Thanks!
*** Bug 501117 has been marked as a duplicate of this bug. ***