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.
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
In the the handling of the "GetAccessibleAtPoint" AT-SPI Component
method, make sure that the context of the accessible at the
given point is realized so that a reference can be returned.
Otherwise, the called `gtk_at_spi_context_to_ref` will return
a null ref instead.
The same is already done in the handling for other AT-SPI methods,
(s. "GetRelationSet", "GetChildren", "GetChildAtIndex" in
gtk/a11y/gtkatspicontext.c).
With this in place, an accessible will be returned.
It's not necessarily the one that's really at the requested location,
but that's a different issue that will be addressed in a separate
commit.
With this in place, example from issue #6448 now gives this result
when using Accerciser's IPython console:
In [16]: acc.queryComponent().getExtents(pyatspi.WINDOW_COORDS)
Out[16]: [0, 0, 800, 600]
In [17]: acc.queryComponent().getAccessibleAtPoint(50, 50, pyatspi.WINDOW_COORDS)
Out[17]: <Atspi.Accessible object at 0x7fae500e8540 (AtspiAccessible at 0x308bf40)>
In [18]: acc.queryComponent().getAccessibleAtPoint(50, 50, pyatspi.WINDOW_COORDS).queryComponent().getExtents(pyatspi.WINDOW_COORDS)
Out[18]: [683, 1, 111, 49]
-> an accessible is returned now, but its rectangle starts at
X coordinate 683, so the requested point (50, 50) is not in its
bounding box.
Issue: #6448
Avoids getting the scale wrong when due to a rounding error our
pixel-aligned rectangle is 5.000000003px big and we ceil() to 6px
and produce blurry output.
Fixes#6439
This tests that the result is suitably clipped for doing linear
blending - the rightmost green pixel that is technically offscreen
is blending into the red pixel and turning the test yellow.
Cairo gets this wrong for some reason I didn't investigate.
The code was written under the assumption that the corners of
the rounded rect are disjoint. If they aren't, there are a few
more cases to consider.
Fixes: #6440
Add rounded rect intersection tests with difficult rounded rects
where the corners are not disjoint (the 'evil eye').
The first half of these tests were provided by Benjamin Otte
in #6440, the other half was added by me to cover the flipped
version of the evil eye.
g_test_init has the ugly habit of aborting if G_DISABLE_ASSERT
is defined, and we want to run our tests in a release build too.
Use gtk_test_init instead, which works around this issue.
We lost this when a bunch of rect code was inlined in
commit 36314f28e2, and as it turns out, that broke some
applications. So, bring it back.
Fixes: #6435
