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
This fixes monitor enter and leave events on X11, and probably other
things. Previously, it looks like the coordinates were relative to the
top left corner of the window shadow and so never changed.
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).
With our custom logic out of the way, this just works.
Maximized state is also update on move, since a moved maximized
window is no longer considered maximized in macOS land.
In macOS, when moving a maximized window, it's not automatically
restored to its default size.
In addition, GdkMacosWindow should not check surface layout properties,
since those properties are lagging, e.i. are set after the (native)
window state has been updated.
GdkSurface maintains state that shadows the actual window state.
This state is not always updated in the macos backend.
In our case, when a window is initially maximized, `setFrame:display:`
was called and `inMaximizeTransition` was set. However,
`windowDidEndLiveResize:` was never called and `inMaximizeTransition`
was never unset, making the application think the window is still
maximized.
Additionally, `windowShouldZoom:toFrame:` is only called when the window
is maximized, not when it's unmaximized.
By checking and setting the state in `windowDidResize:` we can at least
be sure that the internal maximized state is only set if the window
takes up all desktop space: the screen's visible frame.
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.
