Re: Fwd: [orca-list] KDE Plasma 5.15 Task switcher

Hey Chrys.

And I'll reply here because it's of more value here, I think.

Warning: This message is quite long and contains implementation details.
If you're not Chrys or Frederik, you might wish to skip it. :)

Switcher stuff and Orca
========================
Regarding the lack of icon role, keep in mind that it's not so much what
roles exist in Qt but *how those roles get mapped* to the ATK/AT-SPI2
roles. If you use Qt's graphic role, does it get exposed as ROLE_IMAGE
in AT-SPI2? If so, then that's probably not the right thing.

ROLE_LIST_ITEM might work, but a list item needs to live in a list. In
addition, when Orca sees a list item, it tries to present the position
in set and set size -- at least for some users based on their settings.
Thus that might not be the right thing either.

GNOME Shell assigns the push button role. Aside: I think I may suppress
the speaking of that role for GNOME Shell. It tends to be more noise
than value. And we're early in Orca's release cycle. :)

Desktop and Folder View stuff and Orca
======================================
For things with ROLE_ICON and ROLE_CANVAS (which are the roles used for
Gtk+ icon views), Orca only says the role if the item lacks an image
description and a description.

The Gtk+ icon views use the image interface to expose what the icon
looks like. And what the icon looks like is based on the file type. So
if it looks like a folder, "folder" would be a great image description.
If it looks like a plain text file, "text file" or "plain text file"
would be appropriate. If you do that, Orca will stop saying "foo canvas"
and start saying "foo folder" and "foo text file." Note that if
implementing the image interface on these icons would be more overhead
than is desired, putting this information in the object's description
property will also get the job done. Orca's not picky. ;) In fact, this
might be something you can do a patch for yourself:

To verify the solution will work (i.e. just experimenting): Given an
icon for which Orca says "foo canvas" figure out where in the KDE app
"foo" is being assigned as the accessible object's name. In that same
spot, try setting the accessible description using a similar method call
to make it "bar". If, when you arrow to that icon, Orca says "foo bar"
instead of "foo canvas" then you'll know setting the description will
solve the problem. Mind you, setting it there may or may not make sense.
Depends on how the app does things. But my *guess* is that you'll either
want to set the description where the name gets set (if at that point
you can obtain the icon type), or where the icon type gets set (if
there's already an accessible object at that point). Again, you'll have
to look at the code, talk to Frederik and/or other developers, etc.

Regardless, I think that adding those descriptions would be a far nicer
way to solve the "Orca says 'canvas'" problem. What do you think?

Related: The reason this problem doesn't happen in Dolphin's icon view
is that the container is a table thus the icons have ROLE_TABLE_CELL.
The good news is that the result is Orca doesn't say "canvas." The bad
news is that Orca doesn't tell you what kind of icon it is. I think you
could expose the icon type/appearance here in a similar fashion without
changing the role; just adding the description should do. The reason why
is that Orca by default presents descriptions when the focus changes. So
different code is kicking in, but the end result is the same.

The one thing you would *not* want to do, of course, is change the role
in dolphin from ROLE_TABLE_CELL to ROLE_CANVAS. It's like what I said
about the list items earlier. Table cells live in tables; canvases do
not (unless the canvas lives in a table cell). Conversely, tables
contain rows (optionally) and cells. You cannot simply assign what seems
like a logical role *for the item*; you also need to ensure you're that
 role is logical *in the context of the specific accessibility tree.*

Sorry for the long message. I hope it all makes sense. And that Frederik
will correct me regarding anything I said which is bogus for Qt so that
you don't waste time going down the wrong path. :)

--joanie

On 4/10/19 12:11 PM, Chrys wrote:
> Howdy List
> FYI:
> I forward this from orca mailing list to keep you up to date.
> 
> Cheers chrys
> 
> 
> Anfang der weitergeleiteten Nachricht:
> 
>> *Von:* [email protected] <mailto:[email protected]>
>> *Datum:* 10. April 2019 um 17:57:43 MESZ
>> *An:* Joanmarie Diggs <[email protected] <mailto:[email protected]>>
>> *Kopie:* [email protected] <mailto:[email protected]>
>> *Betreff:* *Aw:⁨ [orca-list] KDE Plasma 5.15 Task switcher⁩*
>>
>> Howdy Joanie,
>>
>> for the key event issue:
>> i just picked up this again. i remembered that Kate has the same issue
>> by interrupting. Frederik wired up some experimental code what should
>> fix it in Kate. Maybe it improves the situation here too:
>> https://codereview.qt-project.org/#/c/245319/
>> its still in review currently.
>>
>> as for the filler role, i understand. sounds like something i would be
>> able to change. if it is a "icon" i stay in same trouble as i added
>> the desktop icons accessibility. QT seems not to offer a "Icon" role.
>> https://doc.qt.io/qt-5/qaccessible.html#Role-enum
>> for the destkop icons i used "canvas" but its also not the best
>> solution i think. maybe this needs to get added in QT? Or maybe
>> QAccessible::listItem? the docu says also
>> QAccessible::Graphic "A graphic or picture, e.g. an icon."
>> what sounds wrong somehow? not sure whats the best. but whatever we
>> use, i will sync it up with the desktop icons, as it currently says
>> "Icon Name Canvas" (german lainwand) whats not so elegant as well.
>>
>> cheers chrys
>> Zitat von Joanmarie Diggs <[email protected] <mailto:[email protected]>>:
>>
>>> Hey again.
>>>
>>> I just created an initial script for kwin based on the new switcher
>>> script I created. It improves the situation regarding interrupting
>>> presentation.
>>>
>>> That said: One of the things which causes Orca to interrupt presentation
>>> is keyboard events. We aren't seeing them from kwin. In other words,
>>> when you're in kwin, Orca has no clue that you have pressed any keys. At
>>> least not in my environment (which admittedly is Fedora 29 in which I
>>> installed Plasma packages and dependencies from Fedora 30 which isn't
>>> shipping yet). I believe that if we start getting input events from
>>> kwin, presentation by Orca would be further improved.
>>>
>>> Beyond that, "filler" is a rather unfortunate role for the thing in the
>>> switcher emitting focus-change events. Right now, Orca is looking for
>>> that role in its heuristic for identifying events from the switcher
>>> container for kwin. Any chance we could get another, better role for it?
>>> If so, I'll immediately update the heuristic. :)
>>>
>>> If you look at
>>> https://developer.gnome.org/atk/unstable/AtkObject.html#AtkRole, you'll
>>> see the definition of ATK_ROLE_FILLER is "A object that fills up space
>>> in a user interface". And while the thing on the screen getting
>>> highlighted is arguably an object filling up space in a user interface,
>>> I believe that the closest equivalent in Gtk+ is GtkAlignment ("A widget
>>> which controls the alignment and size of its child"). Fillers are
>>> normally things to be ignored by Orca. To me, the selected thing in kwin
>>> looks more like an icon. And there is an ATK_ROLE_ICON.... I'd entertain
>>> other proposals as well. :)
>>>
>>> Please let me know what you, Frederik, and other members of the KDE
>>> community think about the role change. And also please let me know if
>>> what's in Orca master does indeed make things better with respect to
>>> kwin presentation.
>>>
>>> Thanks!
>>> --joanie
>>>
>>> On 3/13/19 10:45 AM, [email protected]
>>> <mailto:[email protected]> wrote:
>>>> Howdy Joanie,
>>>>
>>>>> Let's start with a debug.out
>>>> ok i will create one as i get back to my computer.
>>>>
>>>>> assuming I would need to build the
>>>>> switcher to get Frederik's fix.
>>>> the fix already landed in Plasma Stable (5.15 from january)
>>>> but i will create a debug out first.
>>>>
>>>> cheers + thx!
>>>> chrys
>>>> Zitat von Joanmarie Diggs <[email protected]
>>>> <mailto:[email protected]>>:
>>>>
>>>>> Hey Chrys.
>>>>>
>>>>> Let's start with a debug.out -- assuming I would need to build the
>>>>> switcher to get Frederik's fix.
>>>>>
>>>>> --joanie
>>>>>
>>>>> On 3/13/19 6:48 AM, [email protected]
>>>>> <mailto:[email protected]> wrote:
>>>>>> Howdy Joanie,
>>>>>>
>>>>>> i would need your help. As i currently test the KWin taskswitcher
>>>>>> fixed
>>>>>> by Frederik (thanks man!), i found it works quite fine at first look.
>>>>>> But orca doesnt interrupt the previouse spoken entry when switching to
>>>>>> another one. what makes it very hard to use as you have to wait all is
>>>>>> spoken.
>>>>>>
>>>>>> can you take a look at this? or will it help if i send you an debug?
>>>>>> does this provide all information?
>>>>>>
>>>>>> Reproduce:
>>>>>> Open Plasma 5.15
>>>>>> Start orca
>>>>>> open multible windows
>>>>>> press alt + Tab to switch windows
>>>>>>
>>>>>> expected result:
>>>>>> Same as in gnome
>>>>>>
>>>>>> current result:
>>>>>> no interruption when entry is changed.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> orca-list mailing list
>>>>>> [email protected] <mailto:[email protected]>
>>>>>> https://mail.gnome.org/mailman/listinfo/orca-list
>>>>>> Orca wiki: https://wiki.gnome.org/Projects/Orca
>>>>>> Orca documentation: https://help.gnome.org/users/orca/stable/
>>>>>> GNOME Universal Access guide:
>>>>>> https://help.gnome.org/users/gnome-help/stable/a11y.html
>>>>>> Log bugs and feature requests at http://bugzilla.gnome.org
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>> _______________________________________________
>> orca-list mailing list
>> [email protected] <mailto:[email protected]>
>> https://mail.gnome.org/mailman/listinfo/orca-list
>> Orca wiki: https://wiki.gnome.org/Projects/Orca
>> Orca documentation: https://help.gnome.org/users/orca/stable/
>> GNOME Universal Access guide:
>> https://help.gnome.org/users/gnome-help/stable/a11y.html
>> Log bugs and feature requests at http://bugzilla.gnome.org