Created attachment 175192 [details] [review]
Focus hacks related to the ctrl+alt+tab popup

Bug 618885#c26 explains the issues that avoids Orca working with the ctrl+alt+tab popup 

This is a quick'n'dirt patch that applies the core focus support on this popup.

Reasons it is a dirty hack:

  * The focus on the selected item is not working fine, as Orca doesn't speech it. Probably because this focus is not done with at the proper place/moment or actor.
  * On _keyPressEvent I return false, so the focus manager gets the event and try to start the keynav machinery, without any change
  * I think that the selection management should change, probably removing this, and using the focused object (selected=>focused). _finish would check the focused item, not the selected one.

Finally I will try to implement the Ctrl+Alt+Tab feature using the selection. The patch I have just set as obsolete was an attempt of use the current working material on St, but this is not the correct approach.

For this I will add some support to selection on StWidget/StContainer itself. Right now I think that the way to go is the next one:

 * Two new properties on StWidget, showing if the widget can be selected, and the other if it is selected (similar to the can_focus recently added)
 * Implement ATK_SELECTION. The problem here is that most of the selection management is done on the js code. So my idea is implement a dummy ATK_SELECTION on the accessible object for StWidget (or StContainer), and as ShellGenericContainer, proxyfy the implementation with signals, so js code can implement this.


This would mean a new CallyActor subclass, the accessible object for StWidget. Anyway I already has this in mind in order to expose the tooltip as the accessible object description.

BTW, this would also solve the issue I raised in this comment:

https://bugzilla.gnome.org/show_bug.cgi?id=621671#c25

about the key focus on the entry, and the item selected with ad-hoc code.

This is the same case. The real key focus is on the entry, but what are you doing is selecting a item below. Those are different things

hm... yes, actually probably a lot of the places I'm using focus i should be using selection instead...

For tracking purposes, I will made a summary of two IRC conversations.

As this change would mean some changes on st itself I approached Dan Winship. My original purpose was being as much atk compliant as possible. But Dan made a good question:

<danw> API: ok. (I assume there are ATs that actually use that api?)

So in order to avoid unnecessary changes, I asked Joanmarie Diggs about it, and Orca doesn't requires all the atk_selection stuff. The conclusion of the talk:

<joanie> Given the limited resources, sure, we could work based on what is currently needed by current tools
<joanie> My point is: If GNOME Voice Control were actively developed and being used, the picture would be different
<joanie> Ideally, there should be a full implementation of Atk. But in the real world, there are insufficient resources.
<joanie> If Orca has what it needs that should be fine. (As Caribou is simulating keypresses)

And in Orca case it is only required to know the current selected object, and the selection change notification.

And as Orca is our "accessibility customer" here, instead of a full atk_selection implementation, I will focus on just implement what Orca requires.

Dan suggested to:

 * Use st_widget_has_style_pseudo_class("selected")"
 * Check that "selected" is the one used on each CSS

Although this would change in the future if GNOME Voice Control or a alternative input method would require it.

Im baking a patch with the accessibility support for StWidget (probably I will upload this on a different bug), but I want to share some discoveries during the "Ctrl+Alt+Tab using selection" work:

* Although Dan Winship's advice was use the pseudo-class to check if the item is selected, in some cases, like this one, the code is using "style-class" ("selected-item-box"). So taking into account this, and that not always the name of the pseudo-class or style-class is just "selected" now the heuristic to decide if a item is selected is:
  * Check if the "style-class" or the "pseudo-class" property has the word "selected".

That seems somewhat more hackish that the previous approach

* I had a little chat with Joanmarie Diggs, because on my first tests, Orca remained silent with any item selected change, although the log showed that Orca detected the selection change. Summarizing the chat, as gnome-shell/cally is doing things out of the common way to do the things, probably we would require to override some behaviour on Orca itself. I will start my tests using the cally script that I created on bug 616206, but I bet that this changes should be on a specific gnome-shell orca script.

Added the bug 636717. It includes some patches, and manages the selection changes explained on the previous comment.

With this patch the Alt+Tab, Ctrl+Alt+Tab popups and the overview search items emit properly the selection change.

In the same way, take into account that as no change was made on Cally script, or a new script was created, Orca doesn't speech this message.

For the interest here, check bug 640057

And for the record it point two missing things right now on St widget, 

  * ATK_STATE_SELECTABLE: a way to explicitly say that you can select and object
  * Implement AtkSelection on the container that holds those selectable objects

Although we would try to workaround that missing things as far as possible.

(In reply to comment #0)

>   * Exception: on the accessibility icon, it doesn't speech properly the
> preferences ui item

Bug 667369, adding the dependency.

> * Focusing on Activities speechs out correctly "Activities" but wrongly speech
> "Panel" (wrong role)

This is being tracked on bug 667432, adding dependency

All the individual aspects for this bug are being tracked by other bugs (Depends list not updated at this moment). And some of them already solved. Right now I don't see the advantage of maintain this meta-bug. So I will close this bug.