Once we figure out what is going on with textures, changes are we'll be
able to let this stay a zero rect. But that is still a bit up in the air right now.
When we close grabbing popups due to an outside
click, check at each level if the click is still
outside. This makes closing the nested popover
menu in the popover on page 3 of widget-factory
work as expected, when you click the menubutton
again.
When an event happens on a non-grabbing popup that hangs off
a grabbing popup, don't trigger the autohide. This makes touch
text handles work inside the popover on page 3 of widget-factory.
We can just call gdk_surface_invalidate_rect here
like we do elsewhere in gdk, and I'm a bit uncertain
about the current code that adds an empty update
region.
The Cairo implementation for the Macos backend uses a toplevel
window with full transparency and a series of NSView to create opaque
regions. This improves compositor performance because it allows the
display server to avoid costly blends.
However, we want to ensure we clip better when exposing the
transparent region so that we only expose the shadows/corners as
necessary.
This typedef was not used in any public APIs, and is
only used in the MacOS backend. It is not worth preserving
as public API, move it to the only user.
This implements the basics for a GdkGLContext on macOS. Currently, rendering
only is fully working for the GskCairoRenderer case where we read back pixels
into a cairo surface for rendering. More work on synchronization is required for
the GL on GskGLRenderer case.
When we attempt to render a surface itself with GL, the context will ensure that
the new GdkMacosGLView is placed within the NSWindow. In other cases, we
use a dummy NSView and NSWindow for backing the NSOpenGLContext to
ensure that we can get accelerated drawing.
This gets GtkGLArea working when running with GSK_RENDERER=cairo.
This helps a situation where the window contents has not changed
in time for a drawing. Setting the texture gravity helps that side or
corner to be less jittery while moving.
Ideally, we can get to a point where we are synchronized and keeping
up with drawing fast enough to not need this. That may require some
work to drive frame clocks from drawRect: though.
The current code was marking queued events as flushed,
but left them in the queue. That doesn't make sense to
me - we should deliver all events we have before we
reach the paint phase of the frame cycle.
GLDEBUGPROC callback is defined with APIENTRY which is a windows
specific calling convention. That macro expands to nothing when building
on other platforms.
Fixes: #3268.
Call SetCapture() explcitly for the (new) modal window so that we make the
modal window respond to mouse input, and also call SetCapture() to the parent
of the transient window that we are destroying so that mouse input capture is
returned to the parent window.
This attempts to fix the following:
* Upon creating a new modal window, the new modal window does not receive
pointer input unless one switches to another program and back
* Upon closing a transient window, the parent window that activated the
transient window does not receive pointer input unless one switches to
another and back
This reverts commit fc2008f2.
Turns out, we *don't* have code to maintain Z-order. Restacking
code is not doint that, it just enforces a few weird Z-order-related
behaviours.
Make sure that we get the state of the modal window properly, and send out the
corresponding notification signals.
This will ensure that we do not try to activate windows that should have become
inactivated due to it opening modal windows and render the program unresponsive
because we are not activating the correct window that is due to receive user
input.
