We are going to use it in the AccessibleText implementations, so there's
no need to have it under a11y.
Also, change the apis from taking a GVariantBuilder to just return
plain arrays.
The AccessibleText interface is meant to be implemented by widgets and
other accessible objects that expose selectable, navigatable, or rich
text to assistive technologies.
This kind of text is not covered by the plain accessible name and
description, as it contains things like a caret, or text attributes.
This commit adds a stub GtkAccessibleText with its basic virtual
functions; the interface will be implemented by widgets like GtkLabel,
GtkInscription, GtkText, and GtkTextView. A further commit will ensure
that the AT-SPI implementation will convert from GTK to AT-SPI through a
generic (internal API); and, finally, we'll remove the widget type
checks in the AT-SPI implementation of GtkATContext, and only check for
GtkAccessibleText.
Fixes: #5912
The use cases for and reasons of having Gtk.SearchEntries
is wide range. Thus, it makes sense to let users of it
manually set input-purpose and input-hints for improved
input method support there.
see: https://gitlab.gnome.org/GNOME/Initiatives/-/issues/50
Signed-off-by: Markus Göllnitz <camelcasenick@bewares.it>
gtk_editable_delete_text() takes a half-open interval, and accepts
an end_pos of -1 to mean 'all the way'. The GtkText implementation
was not handling these details correctly.
Unspecified attributes are not interpreted as "leave this feature out",
rather as "pick a default value". For depth, stencil and accum bits the
defaults may be different than 0. For example, with AMD drivers we get:
* WGL_DEPTH_BITS_ARB: 32
* WGL_STENCIL_BITS_ARB: 8
* WGL_ACCUM_BITS_ARB: 0
Set the attributes to 0 as a hint that depth, stencil and accum buffers
should not be created.
The driver may still create them (matching criteria is "minimum" [1]),
but that's outside of our control (and unlikely to happen).
References:
[1] - WGL_ARB_pixel_format specification
https://registry.khronos.org/OpenGL/extensions/ARB/WGL_ARB_pixel_format.txt
See #6401
The SDKROOT variable is _the_ "master switch" to set the target
OS version (much stricter compared to MACOSX_DEPLOYMENT_TARGET alone),
yet it has no impact on the output of 'xcodebuild -showsdks'.
Also rename the script to 'macos', it's not being called 'osx' anymore
since 2016 (Sierra).
This marks the beginning of transitioning to the arm64 architecture as
the default. The x86_64 job remains present but is being phased out of
24/7 operations, i.e. the job is now on-demand only.
We need to provide pkg-config and bison to build the introspection
feature. They were previously pre-installed on the runner and are now
provided by dedicated projects for better reproducability
to get away from "works on my machine".
They are not required anymore.
Use the system's Python 3 as we no longer need to match the version
with the externally provided wheels for pygobject and pycairo
(courtesy of Inkscape's CI that also runs on that machine).
To make it work on macOS, do not add typelibdir to GI_TYPELIB_PATH.
While this change affects all the other jobs as well, it appears to
be of no consequence.
We were just assuming they were if the format matches.
Fixes crashes in Webkit where the external texture is actually a dmabuf
imported as an EGL image.
Currently dmabuf_dep is found when the following conditions are met:
- linux/dma-buf.h is present;
- libdrm is found.
This is because Linux dmabuf support requires drm_fourcc.h which is part
of libdrm.
However, dmabuf_dep is used for two purposes:
- define HAVE_DMABUF to state dmabuf support;
- ensure the presence of drm_fourcc.h for gdk and for the
media-gstreamer module.
Decouple this, unconditionally check for libdrm and require it on
Linux. Then, use libdrm_dep only to state the drm_fourcc.h presence.
Given that now we unconditionally require libdrm on Linux, HAVE_DMABUF
depends only on the linux/dma-buf.h presence.
In `accessible_at_point`, fix the check whether the
given point is inside of the accessible's bounds.
For that to be the case, the point's x coordinate
must be somewhere between the X position of the
accessible's bounds and that position + width.
(Likewise for the y coordinate and the height.)
the previous check would only work correctly
for children located at a relative location
of (0, 0) within the parent.
With this and the previous commit in place,
the (extended) example from issue #6448 now gives
the expected result:
an accessible object in whose bounds include
requested point (50, 50) lies:
In [19]: acc.queryComponent().getExtents(pyatspi.WINDOW_COORDS)
Out[19]: [0, 0, 800, 600]
In [20]: acc.queryComponent().getAccessibleAtPoint(50, 50, pyatspi.WINDOW_COORDS)
Out[20]: <Atspi.Accessible object at 0x7fae500e9180 (AtspiAccessible at 0x33455b0)>
In [21]: acc.queryComponent().getAccessibleAtPoint(50, 50, pyatspi.WINDOW_COORDS).queryComponent().getExtents(pyatspi.WINDOW_COORDS)
Out[21]: [6, 1, 68, 49]
Fixes: #6448
