Commit Graph

14 Commits

Author SHA1 Message Date
Christian Hergert
9320148d71 macos: implement compute_size and request_layout
These functions were not implemented when the sizing changes
landed before GTK 4 was released. This fixes an issue with non-
resizeable windows not reacting to layout changes.

Fixes #3532
2021-01-01 13:17:47 -08:00
Christian Hergert
62af8365f6 macos: fix toplevel present function prototype
No need to return anything here.
2021-01-01 13:17:47 -08:00
Tom Schoonjans
81c55b06d2 macos: fix typo that breaks compilation 2020-12-16 19:16:19 +00:00
Jonas Ådahl
142f7862ed gdk/toplevellayout: Change API to be about intent, not full state
When being fullscreen, and wanting to unfullscreen but not caring about
whether to go unmaximized or maximized (as this information is lost), if
the GdkToplevelLayout represents the full intended state, we won't be
able to do the right thing.

To avoid this issue, make the GdkToplevelLayout API intend based, where
if one e.g. doesn't call gdk_toplevel_set_maximized() with anything, the
backend will not attempt to change the maximized state.

This means we can also remove the old 'initially_maximized' and
'initially_fullscreen' fields from the private GtkWindow struct, as we
only deal with intents now.
2020-12-16 14:16:08 +01:00
Christian Hergert
0236fe80c1 macos: fix macOS build breakage
Fixes breakages due to recent refactoring around sizing changes.
2020-12-08 11:29:31 -08:00
Jonas Ådahl
6ee7535af0 gdk/toplevelsize: Rename 'margin' to 'shadow' and 'shadow_width'
This makes it more consistent with everywhere else.
2020-12-07 20:37:29 +01:00
Jonas Ådahl
3f96d4b6da gdk: Always get shadow width via GdkToplevelSize
This removes the gdk_surface_set_shadow_width() function and related
vfuncs. The point here is that the shadow width and surface size can now
be communicated to GDK atomically, meaning it's possible to avoid
intermediate stages where the surface size includes the shadow, but
without the shadow width set, or the other way around.
2020-12-07 09:46:39 +01:00
Christian Hergert
9b9fb4d7a3 macos: place above transient-for when presenting
We need to re-attach to the transient-for window whenever we present or
we risk getting placed behind the window by the display server. Apparently
that setting does not persist across a hide of the NSWindow.
2020-12-02 10:21:16 -08:00
Christian Hergert
a020c901ba macos: treat some toplevel NSWindow like document windows
This makes the window animate in by the window manager like other
application windows on macOS. Currently ignored for transient windows.
2020-12-01 16:19:04 -08:00
Christian Hergert
bf3e1e5b40 macos: use opaque GL context when possible
This is better for situations where the window is decorated and therefore we can
rely on window system clipping of rounded corners.
2020-11-05 13:34:29 -08:00
Christian Hergert
58f9413464 macos: track various changes in GDK 2020-10-09 20:02:18 -07:00
Jonas Ådahl
2ff74eb667 gdk/toplevel: Negotiate surface size via a compute-size signal
GTK will not up front know how to correctly calculate a size, since it
will not be able to reliably predict the constraints that may exist
where it will be mapped.

Thus, to handle this, calculate the size of the toplevel by having GDK
emitting a signal called 'compute-size' that will contain information
needed for computing a toplevel window size.

This signal may be emitted at any time, e.g. during
gdk_toplevel_present(), or spontaneously if constraints change.

This also drops the max size from the toplevel layout, while moving the
min size from the toplevel layout struct to the struct passed via the
signal,

This needs changes to a test case where we make sure we process
GDK_CONFIGURE etc, which means we also needs to show the window and
process all pending events in the test-focus-chain test case.
2020-08-05 15:49:00 +02:00
Jonas Ådahl
c7c71137b2 gdk/monitor: Remove gdk_monitor_work_area and GdkMonitor::work-area
It's not a portable API, so remove it. The corresponding backend
specific functions are still available, if they were implemented, e.g.
gdk_macos_monitor_get_workarea() and gdk_x11_monitor_get_workarea().
2020-07-29 17:57:30 +02:00
Christian Hergert
9dbf99d91a macos: prototype new GDK backend for macOS
This is fairly substantial rewrite of the GDK backend for quartz and
renamed to macOS to allow for a greenfield implementation.

Many things have come across from the quartz implementation fairly
intact such as the eventloop integration design and discovery of
event windows from the NSEvent.

However much has been changed to fit in with the new GDK design and
how removal of child GdkWindow have been completely eliminated.
Furthermore, the new GdkPopup allows for regular NSWindow to be used
to provide popovers unlike the previous implementation.

The object design more closely follows the ideal for a GDK backend.

Views have been broken out into subclasses so that we can support
multiple GSK renderer paths such as GL and Cairo (and Metal in the
future). However mixed mode GL and Cairo will not be supported. Currently
only the Cairo renderer has been implemented.

A new frame clock implementation using CVDisplayLink provides more
accurate information about when to draw drawing the next frame. Some
testing will need to be done here to understand the power implications
of this.

This implementation has also gained edge snapping for CSD windows. Some
work was also done to ensure that CSD windows have opaque regions
registered with the display server.

     ** This is still very much a work-in-progress **

Some outstanding work that needs to be done:

 - Finish a GL context for macOS and alternate NSView for GL rendering
   (possibly using speciailized CALayer for OpenGL).
 - Input rework to ensure that we don't loose remapping of keys that was
   dropped from GDK during GTK 4 development.
 - Make sure input methods continue to work.
 - Drag-n-Drop is still very much a work in progress
 - High resolution input scrolling needs various work in GDK to land
   first before we can plumb that to NSEvent.
 - gtk/ has a number of things based on GDK_WINDOWING_QUARTZ that need
   to be updated to use the macOS backend.

But this is good enough to start playing with and breaking things which
is what I'd like to see.
2020-07-21 14:45:12 -07:00