GNOME Bugzilla – Bug 685621
object state-changed:selected not raised and no accessible name displayed when alt+esc pressed
Last modified: 2014-12-29 06:56:30 UTC
Created attachment 225948 [details] Sample output from script When the key sequence alt+esc is used to cycle between windows, there are state-changed event issues. This causes a problem with orca. When the key sequence alt+esc is pressed: 1) the event object:state-changed:showing is raised, but this is not ideal. It would be better if object:state-changed: selected were to be raised (just like what happens when alt+tab is pressed) 2) Currently, the object:state-changed:showing has role "panel" (but this is too generic), 3) This event must present the title through the accessible name. Attached is the event listener script that indicates that when alt+esc is pressed, and object:state-changed:showing is raised with no "panel" name. Also attached is the output from our sample tests of this bugs.
Created attachment 225949 [details] the listener script
*** Bug 685472 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > 1) the event object:state-changed:showing is raised, but this is not ideal. It > would be better if object:state-changed: selected were to be raised (just like > what happens when alt+tab is pressed) I will look if there is a way to emit that event. > 2) Currently, the object:state-changed:showing has role "panel" (but this is > too generic), As you are saying that panel role is too generic, any suggestion about the role to be used? > 3) This event must present the title through the accessible name. ok. > Attached is the event listener script that indicates that when alt+esc is > pressed, and object:state-changed:showing is raised with no "panel" name. Also > attached is the output from our sample tests of this bugs. I think that I don't fully understand this paragraph. Specifically "is raised with no "panel" name". Seems to suggest that the role is not there. Reading 2 I understand that the role is panel. Do you mean "is raised with "panel" role but without name"?
(In reply to comment #3) > As you are saying that panel role is too generic, any suggestion about the role > to be used? Yes, panel is too generic. In terms of an alternative role, as we were discussing at the Summit, how about role window since alt+esc is cycling through / selecting amongst windows. > Do you mean "is raised with "panel" role but without name"? Yes.
Created attachment 226085 [details] [review] Proof of concept patch This is a temptative patch that solves the three missing stuff mentioned at comment 0. In the end it is not a gnome-shell bug, but a mutter bug. GNOME Shell doesn't do that anything in relation with the cycle-windows keybindings. I basically added accessibility information to the mutter object MetaWindowActor. I didn't create an custom accesssibility object subclass, as it would be an overkill. I just used atk API About the role, I set it to ATK_ROLE_WINDOW, as suggested at comment 4. Taking into account that the object itself is called MetaWindowActor, it fits really well. The title was also easy. The MetaWindow associated to this MetaWindowActor has a method _get_title, so I just used it as the name. The tricky part is about the event emission. I was waiting for a kind of flag on MetaWindowActor pointing when to draw the outline, so emitting the selection event would be as easy as tracking that flag. But as Jasper pointed to me, the outline is draw at tabPopup.c A custom mutter tabpopup is created on the handle to cycle-windows keybinding, specifically at do_choose_window. And the outline is drawn externally. For me the easiest place to send that atk-selected event is when the window is raised (I added a callback to the property notification). At some sense, they keybinding management code is using meta_window_raise as a way to do the same thing. Anyway, not sure if this is the proper place to do that. After some first provisional tests with Orca, this seems to work. Having said so. Jasper also mentioned that Alt+Esc is somewhat broken and that the people are not really happy with it. Also mentioned that drop this feature is a possibility. Taking that into account not sure if it is worth to add the accessibility support for that feature.
(In reply to comment #5) > Having said so. Jasper also mentioned that Alt+Esc is somewhat broken and that > the people are not really happy with it. Also mentioned that drop this feature > is a possibility. Taking that into account not sure if it is worth to add the > accessibility support for that feature. Apologies. I went back and double-checked and the actual reply was to move the code from GTK+ painting to being in the compositor. See: https://bugzilla.gnome.org/show_bug.cgi?id=671937
(In reply to comment #6) > (In reply to comment #5) > > Having said so. Jasper also mentioned that Alt+Esc is somewhat broken and that > > the people are not really happy with it. Also mentioned that drop this feature > > is a possibility. Taking that into account not sure if it is worth to add the > > accessibility support for that feature. > > Apologies. I went back and double-checked and the actual reply was to move the > code from GTK+ painting to being in the compositor. > > See: https://bugzilla.gnome.org/show_bug.cgi?id=671937 Interesting lecture. That "something like meta_window_actor_set_highlighted" method proposed by Owen Taylor at bug 671937 comment 10 is more or less that "kind of flag on MetaWindowActor" that I mentioned at comment 5 I like to have. With that kind of method, knowing when a window is selected or when to emit that the window get selected would be trivial. Basically if a window is highlighted it is selected. And as Owen said, that would be also avoid stacking order issues. On the patch I uploaded at comment 5, I'm implying that any window raised on the stack is selected, when this is debatable as a general rule. So taking into account that how and when the windows under a cycle-window is highlighted is being refined at that bug, and could change, I think that it would be safer to wait until that bug got solved. So adding a dependency with that bug.
The same thing happens when using alt + f6 to navigate between the windows of an application. Orca is muted and only announces the name of the window when we release the alt key.
Alt+Esc doesn't exist anymore.