gtk issueshttps://gitlab.gnome.org/GNOME/gtk/-/issues2024-03-22T17:51:59Zhttps://gitlab.gnome.org/GNOME/gtk/-/issues/562GTKFileChooser should provide a shortcut for focus the file list2024-03-22T17:51:59ZBugzillaGTKFileChooser should provide a shortcut for focus the file list## Submitted by chris
**[Link to original bug (#752220)](https://bugzilla.gnome.org/show_bug.cgi?id=752220)**
## Description
Hi all,
it would be helpfull if the GTKFileChooser provides a shortcut for focusing the "file entry table"...## Submitted by chris
**[Link to original bug (#752220)](https://bugzilla.gnome.org/show_bug.cgi?id=752220)**
## Description
Hi all,
it would be helpfull if the GTKFileChooser provides a shortcut for focusing the "file entry table"
so you could easily jump beween places/ locationbar and files table.
this would the filechooser realy more accessible for keyboard users :).
Version: 3.22.x
### See also
* [Bug 753892](https://bugzilla.gnome.org/show_bug.cgi?id=753892)https://gitlab.gnome.org/GNOME/gtk/-/issues/6495Unable to notify changes to non GtkWidget GtkAccessible object trees2024-03-12T03:30:34ZRobert AncellUnable to notify changes to non GtkWidget GtkAccessible object treesIf a tree of objects is exposed on the accessibility bus using GtkAccessible that are not GtkWidgets then there is no way to notify when the tree changes, thus the tree functions `GtkAccessible.get_first_accessible_child` etc are only ca...If a tree of objects is exposed on the accessibility bus using GtkAccessible that are not GtkWidgets then there is no way to notify when the tree changes, thus the tree functions `GtkAccessible.get_first_accessible_child` etc are only called once. GtkWidget notifies when these change by calling `gtk_accessible_update_children`, which is private API. There will also be the same issue for the bounds of the objects which is notified using `gtk_accessible_bounds_changed`.
The particular case I'm doing is exposing accessibility information in a Flutter application where the Flutter widgets are not rendered by GTK. It appeared to me that you should be able to expose accessibility information like this using GTK (as was possible in GTK 3), but perhaps that is not the expectation anymore or there is another method of doing this.https://gitlab.gnome.org/GNOME/gtk/-/issues/6449Accessible object:state-changed:checked event spam for non-visible, non-chang...2024-03-11T10:43:24ZJoanmarie DiggsAccessible object:state-changed:checked event spam for non-visible, non-changed widgets during window activation/deactivationSteps to reproduce:
1. Run and launch this script in gnome-terminal:
```
#!/usr/bin/python3
import pyatspi
def listener(e):
print(f"{e.source.name} is checked: {e.detail1}")
pyatspi.Registry.registerEventListener(listener, "object...Steps to reproduce:
1. Run and launch this script in gnome-terminal:
```
#!/usr/bin/python3
import pyatspi
def listener(e):
print(f"{e.source.name} is checked: {e.detail1}")
pyatspi.Registry.registerEventListener(listener, "object:state-changed:checked")
pyatspi.Registry.start()
```
2. Launch gedit
3. Alt+Tab or click to switch between the two apps
Expected results: No object:state-changed:checked events would be listed in gnome-terminal
Actual results: Every time gedit gains or loses focus it fires several object:state-changed:checked events for items that are not on screen and whose state hasn't changed. Ditto for gnome-terminal.
@tyrylu: Could you please look into this and ideally make it stop?https://gitlab.gnome.org/GNOME/gtk/-/issues/6488SEGV in accessible_text_handle_method with no selection2024-02-29T03:52:12ZMarkus GöllnitzSEGV in accessible_text_handle_method with no selectionWhen there is a Gtk.Text that has no selection, there is a segmentation violation when orca is on:
received signal SIGSEGV, Segmentation fault.
#0 0x00007ffff71bbf9a in accessible_text_handle_method (connection=<optimized ...When there is a Gtk.Text that has no selection, there is a segmentation violation when orca is on:
received signal SIGSEGV, Segmentation fault.
#0 0x00007ffff71bbf9a in accessible_text_handle_method (connection=<optimized out>, sender=<optimized out>, object_path=<optimized out>, interface_name=<optimized out>, method_name=<optimized out>, parameters=0x7fffe80071e0, invocation=0x7fffe80170a0, user_data=0x555556f27350) at ../gtk/a11y/gtkatspitext.c:257
start = <optimized out>
end = <optimized out>
num = 0
n_ranges = 140737488344032
ranges = 0x0
self = 0x555556f27350
accessible = 0x555556f26eb0
accessible_text = 0x555556f26eb0https://gitlab.gnome.org/GNOME/gtk/-/issues/6481Add MSAA support (legacy Windows accessibility API)2024-02-27T12:01:59ZBruno LopesAdd MSAA support (legacy Windows accessibility API)Actually, is impossible to use Windows screen reader in GTK apps (aka GIMP and Inkscape) because the GDK seems to not support MSAA yet. This is quite sad to blind users.Actually, is impossible to use Windows screen reader in GTK apps (aka GIMP and Inkscape) because the GDK seems to not support MSAA yet. This is quite sad to blind users.https://gitlab.gnome.org/GNOME/gtk/-/issues/310Accelerator/Search support for combobox items2024-02-26T15:17:38ZBugzillaAccelerator/Search support for combobox items## Submitted by Luca Bruno
**[Link to original bug (#567141)](https://bugzilla.gnome.org/show_bug.cgi?id=567141)**
## Description
Hello,
I'd like to suggest a new feature for GtkComboBox, which is included in other toolkits and also...## Submitted by Luca Bruno
**[Link to original bug (#567141)](https://bugzilla.gnome.org/show_bug.cgi?id=567141)**
## Description
Hello,
I'd like to suggest a new feature for GtkComboBox, which is included in other toolkits and also browsers.
For long combo lists it's often boring to scroll the whole list before getting to an item. If items had accelerators or a kind of search, the user could use the keyboard to select the item.
I said "accelerator" but it's mandatory to use the first letters of the item, underlines would confuse the user.
Other information:
Suggested behavior:
1. When the user starts typing some keys the matching items in the combobox must be selected.
2. Pressing multiple keys is supported within a keyboard timeout (e.g. 1 second between each key) to improve the search pattern then select a more specific item.
3. API will expose a property for specifying which column of the model is going to be used for the search, though the cell renderer must be textual and visible to the user.
Version: 3.91.xhttps://gitlab.gnome.org/GNOME/gtk/-/issues/6462GtkAccessibleRole lacks terminal enum value2024-02-22T15:33:35ZChristian HergertGtkAccessibleRole lacks terminal enum valueVTE for GTK 3 uses `ATK_ROLE_TERMINAL` and `ATSPI_ROLE_TERMINAL` does exist in `gtk/a11y/gtkatspiprivate.h` but we are not exposing it.
Is there a reason for omitting it (like is the role useless now days and we should just use `GTK_ACC...VTE for GTK 3 uses `ATK_ROLE_TERMINAL` and `ATSPI_ROLE_TERMINAL` does exist in `gtk/a11y/gtkatspiprivate.h` but we are not exposing it.
Is there a reason for omitting it (like is the role useless now days and we should just use `GTK_ACCESSIBLE_ROLE_TEXT`) or should I add it?
/CC @ebassihttps://gitlab.gnome.org/GNOME/gtk/-/issues/3376Optimise handling of presentational widgets2024-02-22T13:07:15ZEmmanuele BassiOptimise handling of presentational widgetsWe're emitting a lot of `org.a11.atspi.Cache.AddAccessible` signals, but some of this work is not necessary:
- presentational children are not important, and should be ignored
- we can have fast paths for the first and last children o...We're emitting a lot of `org.a11.atspi.Cache.AddAccessible` signals, but some of this work is not necessary:
- presentational children are not important, and should be ignored
- we can have fast paths for the first and last children of a widget, if they are not presentational
- we should not go through GtkAccessible unless strictly necessaryEmmanuele BassiEmmanuele Bassihttps://gitlab.gnome.org/GNOME/gtk/-/issues/5912Add GtkAccessibleText interface for text widgets2024-02-20T19:22:03ZEmmanuele BassiAdd GtkAccessibleText interface for text widgetsNow that `GtkAccessible` is public, we're going to need a public interface for widgets that provide textual data.
Implementation details:
- AT-SPI: https://gnome.pages.gitlab.gnome.org/at-spi2-core/devel-docs/doc-org.a11y.atspi.Text.ht...Now that `GtkAccessible` is public, we're going to need a public interface for widgets that provide textual data.
Implementation details:
- AT-SPI: https://gnome.pages.gitlab.gnome.org/at-spi2-core/devel-docs/doc-org.a11y.atspi.Text.html
- UIAutomation: https://learn.microsoft.com/en-us/dotnet/api/system.windows.automation.provider.itextprovider?view=windowsdesktop-7.0
- NSAccessibilityProtocol: https://developer.apple.com/documentation/appkit/nsaccessibilityprotocol#1674786
See also: https://gitlab.gnome.org/GNOME/vte/-/issues/2614https://gitlab.gnome.org/GNOME/gtk/-/issues/6454Accessible description read twice by Orca when using gtk_accessible_update_pr...2024-02-19T16:42:37ZMarkus GöllnitzAccessible description read twice by Orca when using gtk_accessible_update_propertyWhen `gtk_accessible_update_property` with a description is called between construction and rooting of a widget, the description is read twice by orca, when the widget receives focus for the first time.
I saw that an `object:property-ch...When `gtk_accessible_update_property` with a description is called between construction and rooting of a widget, the description is read twice by orca, when the widget receives focus for the first time.
I saw that an `object:property-change:accessible-description` ATSPI event is sent when the widget is focussed, and not before.
The application I used to hear the description read twice with orca:
```
#include <gtk/gtk.h>
static void
on_activate_cb (GtkApplication *application,
gpointer basically_a_fancy_null_pointer)
{
GtkApplicationWindow *window;
GtkBox *box;
GtkButton *button_without_description;
GtkButton *button_with_description;
window = GTK_APPLICATION_WINDOW (gtk_application_window_new (application));
gtk_window_set_title (GTK_WINDOW (window), "This is weird, isn't it?");
gtk_window_set_default_size (GTK_WINDOW (window), 300, 200);
box = GTK_BOX (gtk_box_new (GTK_ORIENTATION_VERTICAL, 12));
button_without_description = GTK_BUTTON (gtk_button_new_with_label ("Do Not Click"));
button_with_description = GTK_BUTTON (gtk_button_new_with_label ("Do Nothing!"));
gtk_accessible_update_property (GTK_ACCESSIBLE (button_with_description),
GTK_ACCESSIBLE_PROPERTY_DESCRIPTION,
"A description so fancy, you want to hear it twice.",
-1);
gtk_box_append (box, GTK_WIDGET (button_without_description));
gtk_box_append (box, GTK_WIDGET (button_with_description));
gtk_window_set_child (GTK_WINDOW (window), GTK_WIDGET (box));
gtk_window_present (GTK_WINDOW (window));
}
int
main (int argc,
char **argv)
{
GtkApplication *application;
int status;
application = gtk_application_new("it.bewares.snippets.A11yDescription",
G_APPLICATION_DEFAULT_FLAGS);
g_signal_connect (application, "activate", G_CALLBACK (on_activate_cb), NULL);
status = g_application_run (G_APPLICATION (application), argc, argv);
g_object_unref (application);
return status;
}
```
The first button is not important here, but it helps with checking when said ATSPI event is received on. I am not sure, it is related to the issue. I wanted to include all my findings nonetheless.
The script I used to check when the ATSPI event came in:
```
#!/usr/bin/env python3
import pyatspi
pyatspi.Registry.registerEventListener(lambda e: print(e), "object:property-change:accessible-description")
pyatspi.Registry.start()
```
Tested with versions
* ATSPI 2.50.0
* GTK 4.12.5 and 4.13.8-90d84a2
* Orca 45.2https://gitlab.gnome.org/GNOME/gtk/-/issues/6358Support accessibility relation lists in bindings such as GJS and Python2024-01-26T10:52:27ZEvan Welshcontact@evanwelsh.comSupport accessibility relation lists in bindings such as GJS and PythonThis is follow-up from [this GJS issue](https://gitlab.gnome.org/GNOME/gjs/-/issues/392)
## Background
Currently when using GTK4 in GJS it is not possible to use accessibility relations such as `LABELLED_BY` because they require passin...This is follow-up from [this GJS issue](https://gitlab.gnome.org/GNOME/gjs/-/issues/392)
## Background
Currently when using GTK4 in GJS it is not possible to use accessibility relations such as `LABELLED_BY` because they require passing a list of pointers inside of a GValue array.
The current signature is...
```
GDK_AVAILABLE_IN_ALL
void gtk_accessible_update_relation_value (GtkAccessible *self,
int n_relations,
GtkAccessibleRelation relations[],
const GValue values[]);
```
To use GJS as an example, we can generally convert values to `GValue` and support this signature. The issue arises with this code:
```
widget.update_relation([Gtk.AccessibleRelation.LABELLED_BY], [[label1, label2]])
```
We can convert `[...]` into an array of GValues, but there is no way to convert `[label1, label2]` into a GValue - GValue has no built-in "list" notion.
## Proposals
There are several ways we could go about solving this - we could even combine aspects of both methods. Regardless, GJS will likely need an override to make the existing `update_relation` work as expected without user intervention.
### Adding a boxed type
To support the existing signature GJS needs a way to "wrap" `[label1, label2]` in a type it knows how to pass, a boxed type would work for this purpose:
```
widget.update_relation(Gtk.AccessibleRelation.LABELLED_BY, new Gtk.AccessibleRelationList([label1, label2]);
```
We could either add `Gtk.AccessibleRelationList` or perhaps `Gtk.AccessibleList` to keep it more generic. This boxed type would hold a reference to a list of GtkAccessible pointers.
We can then update GTK's internally handling to check if the passed GValue is BOXED or not, and in the BOXED case unwrap this type.
### Adding new singular utility functions
We could also add new functions which avoid handling multiple relations at a time...
```
// Not sure what to name this given the current functions are singular, though perhaps we could expose this as-is given the current renaming
gtk_accessible_update_relation_value (GtkAccessibleRelation relation, GValue value);
gtk_accessible_update_relation_values (GtkAccessibleRelation relation, int n_values, GValue[] values);
```
This solves the issue by offering a "single value" utility function and a "multiple values" utility function, I believe GJS would be able to handle both of these without issue.
The hard part is naming given the current functions are "singular" but update multiple relations at once
### Adding utility functions which handle specific relation types
I'm not a huge fan of this option, given we already have the `init_value` utilities and this isn't as obvious for users... but we could also expose functions which are specific to the type of the relation value.
```
gtk_accessible_update_relation_string_value (GtkAccessibleRelation relation, const char* str);
gtk_accessible_update_relation_object_value (GtkAccessibleRelation relation, GtkAccessible* acc);
gtk_accessible_update_relation_list_value (GtkAccessibleRelation relation, int n_values, GValue[] values);
```
## Exploration
I've started cleaning up some thoughts I had on the boxed type [here](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6807)
cc @ebassihttps://gitlab.gnome.org/GNOME/gtk/-/issues/6331Orca can't properly read a GtkColorButton2024-01-21T13:33:27ZAutomeris naranjaOrca can't properly read a GtkColorButton## Affected versions
- gtk4-4.12.4-1.fc39.x86_64
- gnome-control-center-45.2-1.fc39.x86_64
- orca-45.1-1.fc39.noarch
## Steps to reproduce
1. Enable the screen reader (Settings > Accessibility > Seeing)
2. In Settings, go to Accessibil...## Affected versions
- gtk4-4.12.4-1.fc39.x86_64
- gnome-control-center-45.2-1.fc39.x86_64
- orca-45.1-1.fc39.noarch
## Steps to reproduce
1. Enable the screen reader (Settings > Accessibility > Seeing)
2. In Settings, go to Accessibility > Zoom
3. Focus on the "Color" row
4. Press `tab` to focus on the color chooser button
## Seen behavior
Orca will read the following:
`List with five items. Red 100%, green 0%, blue 0%, alpha 66% push button`
Adding a tooltip or an a11y label to GtkColorButton doesn't fix the problem.https://gitlab.gnome.org/GNOME/gtk/-/issues/4241Push button using use_underline gets a duplicate accessible name and the labe...2023-11-23T13:28:56ZLukáš TyrychtrPush button using use_underline gets a duplicate accessible name and the labelled by relation confuses Orca furtherWhen you create a push button with a label and set the use_underline property, it gets an accessibility LABELLED_BY relation via the label's set_underline machinery. Afterwards, when the atcontext's name property is calculated, the butto...When you create a push button with a label and set the use_underline property, it gets an accessibility LABELLED_BY relation via the label's set_underline machinery. Afterwards, when the atcontext's name property is calculated, the button's label attribute is used, but the logic also recurses through the relation, so it appends the same label a second time to the object's name.
To add to it, the default button presentation in Orca sees the label a second time, so the user gets the button's label repeated three times. The labelled by property in this case causes more harm than good, but i am not exactly certain how to solve this. So, any feedback is welcome.https://gitlab.gnome.org/GNOME/gtk/-/issues/3891Orca stays silent when going back to the first item of the gtk4-demo left pane2023-11-23T13:19:46ZAlex ARNAUDOrca stays silent when going back to the first item of the gtk4-demo left paneHello,
Environment:
* Debian Testing
* GNOME 3.38.4
* GTK 4 from a11y-debug branch
Steps to reproduce:
1) Start gtk4-demo with Orca enabled
2) Press down arrow, Orca will say "application class"
3) Press up arrow
Result:
Orca stays si...Hello,
Environment:
* Debian Testing
* GNOME 3.38.4
* GTK 4 from a11y-debug branch
Steps to reproduce:
1) Start gtk4-demo with Orca enabled
2) Press down arrow, Orca will say "application class"
3) Press up arrow
Result:
Orca stays silent.
Expected result:
Orca should announce the new item with the focus "GTK Demo".
Thanks in advance.https://gitlab.gnome.org/GNOME/gtk/-/issues/5144GtkListboxRow: How to convey the activatable state for A11Y?2023-11-22T16:06:38ZLukáš TyrychtrGtkListboxRow: How to convey the activatable state for A11Y?When an user of the GtkListboxRow uses the activatable property to allow activation of the row, they most likely indicate the fact using an image, like, for example, the gnome-control-center folks in the users dialog. However, except for...When an user of the GtkListboxRow uses the activatable property to allow activation of the row, they most likely indicate the fact using an image, like, for example, the gnome-control-center folks in the users dialog. However, except for eperimentation, a visually impaired user can not tell these rows apart from the others except for experimentally activating each of these. How would you go about fixing this, except for changing the rows to GtkButtons, which might not be liked by the developers much? I was thinking about changing the role to a button, however according to the docs, changing the A11Y role after creating the control is not possible, so who knows what would happen... Any ideas?https://gitlab.gnome.org/GNOME/gtk/-/issues/4840GtkListView: Use only arrow keys to navigate rows2023-08-27T11:48:01ZJulian Sparberjulian@sparber.netGtkListView: Use only arrow keys to navigate rowsI think it would be good to change the `tab` behavior for `GtkListView`s. Since it makes moving around the window via `tab` quite annoying because the user needs to go trough the entire list before going to the next widget.
Suggested be...I think it would be good to change the `tab` behavior for `GtkListView`s. Since it makes moving around the window via `tab` quite annoying because the user needs to go trough the entire list before going to the next widget.
Suggested behavior:
- Use tab only to enter and exit the `Gtk.ListView`
- Use only the arrows to navigate the rows of the `Gtk.Listview`
For context: https://gitlab.gnome.org/GNOME/fractal/-/issues/197https://gitlab.gnome.org/GNOME/gtk/-/issues/5999GtkMenuButton within a GtkHeaderbar cannot be navigated to/from with the keyb...2023-08-14T14:12:25ZJeff FortinGtkMenuButton within a GtkHeaderbar cannot be navigated to/from with the keyboard with Tab / Shift+Tab since GTK 4.11.xIn GNOME Calendar's development version (in the event editor dialog), we have found an accessibility regression where a MenuButton flanked by two regular buttons, in a HeaderBar, like this...
![image](/uploads/43097e0dba1c5538cb95efe6cc...In GNOME Calendar's development version (in the event editor dialog), we have found an accessibility regression where a MenuButton flanked by two regular buttons, in a HeaderBar, like this...
![image](/uploads/43097e0dba1c5538cb95efe6cc8f210b/image.png)
i.e. this widget tree:
![image](/uploads/d99bc593c2c09c4b063975f15bb46183/image.png)
...manifests the following symptoms/problems:
* When the MenuButton widget is focused (as shown highlighted in blue in the screenshot above), you can't `Tab` to the next widget (the Done button, or whatever else in the window), it stays stuck there.
You can, however, `Shift+Tab` to the previous widget (the "Cancel" button on the left)
* When the following widget (the "Done" button on the right) is focused, you can't `Shift+Tab` to focus the MenuButton on its left, the focus stays stuck on the "Done" button
It apparently only happens with GTK 4.11.x (in my case, this currently means GTK 4.11.5):
* GNOME Calendar 44.1 from Fedora 38 (running GTK 4.10.4) does not exhibit this issue.
* Building GNOME Calendar git/45.x against the GNOME 44 runtime (thus GTK 4.10.x) also does not exhibit the issue.
---
Just for completeness' sake, GNOME Calendar 44.1 had this widget tree, but in any case this shouldn't affect things, presumably:
![image](/uploads/155d7d521478ae9f3d1cb79d26d27597/image.png)https://gitlab.gnome.org/GNOME/gtk/-/issues/5161Accessible table-cell interface broken for first row2023-07-28T08:42:36ZJoanmarie DiggsAccessible table-cell interface broken for first rowSteps to reproduce:
1. Launch gtk3-demo (I'm using 3.24.34)
2. Launch this pyatspi event-listener in a terminal: [table-cell.py](/uploads/5da18b2bb1d32263707a06176a17a3b9/table-cell.py)
3. Arrow up and down among the available demos in t...Steps to reproduce:
1. Launch gtk3-demo (I'm using 3.24.34)
2. Launch this pyatspi event-listener in a terminal: [table-cell.py](/uploads/5da18b2bb1d32263707a06176a17a3b9/table-cell.py)
3. Arrow up and down among the available demos in the left pane
Expected results: The listener would always report the correct row and column as the selected item changes.
Actual results: Arrowing to the first item (Application Class) causes the listener to state that an exception was handled. The other rows seem fine.https://gitlab.gnome.org/GNOME/gtk/-/issues/5915a11y: GtkPasswordEntry's peek icon is missing a label2023-06-23T22:38:27ZMaximilianoa11y: GtkPasswordEntry's peek icon is missing a labelAs the title says, the a11y warning overlay in the inspector will say that the image is missing a label.As the title says, the a11y warning overlay in the inspector will say that the image is missing a label.https://gitlab.gnome.org/GNOME/gtk/-/issues/908GtkNotebookPage unable to set tab accessibility name2023-06-22T01:17:30ZBugzillaGtkNotebookPage unable to set tab accessibility name## Submitted by Marcin
**[Link to original bug (#787618)](https://bugzilla.gnome.org/show_bug.cgi?id=787618)**
## Description
Created attachment 359699
Example setting up notebook accessibility name
It seems that there's no way to ...## Submitted by Marcin
**[Link to original bug (#787618)](https://bugzilla.gnome.org/show_bug.cgi?id=787618)**
## Description
Created attachment 359699
Example setting up notebook accessibility name
It seems that there's no way to set GtkNotebookPage an accessibility name. In the given exampleI've set the acc name to notebook, label and box. When browsing the acc using Accercisser it will always display text of label_page1.
Tried to search for it in the docs but it seems there's no way to set the acc name for the tab.
The atk code instead is trying to get the name from ATK_ROLE_TAB_PAGE object as can be seen below but it's always null.
static const gchar *
gtk_notebook_page_accessible_get_name (AtkObject *accessible)
{
GtkWidget *label;
if (accessible->name != NULL)
return accessible->name;
label = get_label_from_notebook_page (GTK_NOTEBOOK_PAGE_ACCESSIBLE (accessible));
if (GTK_IS_LABEL (label))
return gtk_label_get_text (GTK_LABEL (label));
return NULL;
}
Based on the above I've set this to blocker as there's no work around of this.
**Attachment 359699**, "Example setting up notebook accessibility name":
[notebook_bug.py](/uploads/dc3d3dc0447c3945e3bfbb6162df922b/notebook_bug.py)
Version: 3.22.x