1) In the SetWindowPos() function (and the WINDOWPOS struct) the
"hWndInsertAfter" argument/field means the window that will be
directly above after the change, not the window that will be
directly below. MSDN says "precedes" for SetWindowPos(), but
WINDOWPOS documentation is more precise: this is the window
behind which the affected window will be placed. Apparently,
Z-axis goes back-to-front.
Therefore, logging should be reworded correctly.
2) When we switch away from the application and then switch back
to a transient window, we need to bring up its transient-owner
(and its transient-owner's owner and so forth) as well,
otherwise our transient (modal) window might be transient for
something that might not be visible.
3) When we bring up a window, we should bring all of its children
(popup windows) on top of it.
Because Windows doesn't provide a function to bring one window
on top of the other, we have to work around this by calling
SetWindowPos() twice, swapping the windows between the calls.
Similar to previous removals of g_cclosure_marshal_VOID__VOID we can remove
other marshallers for which are a simple G_TYPE_NONE with single parameter.
In those cases, GLib will setup both a c_marshaller and va_marshaller for
us. Before this commit, we would not get a va_marshaller because the
c_marshaller is set.
Related to GNOME/Initiatives#10
This uses the new sysprof-3 ABI to implement the capture writer. It also
uses the statically linked libsysprof-capture-3.a that is provided with
Sysprof for the capture writing to ensure that we do not leak any symbols
nor depend on any additional libraries.
The GTK_TRACE_FD can be used to pass a FD for tracing into Gtk. Sysprof
uses this when the Gtk instrument is selected for recording.
If we set c_marshaller manually, then g_signal_newv() will not setup a
va_marshaller for us. However, if we provide c_marshaller as NULL, it will
setup both the c_marshaller (to g_cclosure_marshal_VOID__VOID) and
va_marshaller (to g_cclosure_marshal_VOID__VOIDv) for us.
Root coordinates are going away, so this
api does not make sense anymore. Use
gdk_surface_get_device_position instead.
We still keep this as internal api for
root-coordinate using backends.
The X backend was storing global coordinates
in surface->x/y, and keeping the parent-relative
positions in its own fields. Switch this around
to store the relative position in x/y, as is
expected by the frontend.
This function returns the position relative to
the surface parent, so will always return 0 for
non-popups. The out arguments don't need to
allow-none either - nobody passes NULL for these.
We maintain offsets for popups, so we can translate
coordinates between surfaces that are attached directly
or indirectly to the same toplevel. Add an api for that.
CSS does not do exponents, so printing numbers close to 0 as 1.234e-15
does not work.
Also up the accuracy to 17 digits because that's what everyone else
uses.
GTK4 doesn't have WS_CHILD windows anymore, so hWndParent argument
to CreateWindowEx() is always interpreted as the owner window,
not the parent window.
A window with an owner:
* is above the owner in Z-order
* is destroyed when the owner is destroyed
* is hidden when the owner is minimized
This is enforced by the OS.
GTK can only allow this for popup windows.
Desktop window must never[0] be an owner.
[0]: https://devblogs.microsoft.com/oldnewthing/20040224-00/?p=40493
Popups can't be active or inactive, so emitting GDK events
in response to WM_ACTIVATE makes no sense for these kinds
of GDK surfaces.
The jury is still out on whether we should block (return 0)
or ignore (don't return anything) this message.
Blocking WM_NCACTIVATE (which we currently ignore) is definitely
not an option - it completely breaks input somehow.
1) Handle GDK_SURFACE_POPUP in RegisterGdkClass()
(for now pretend it's the same as GDK_SURFACE_TOPLEVEL)
2) Remove useless code from GDK_SURFACE_TOPLEVEL case in _gdk_win32_display_create_surface()
(now there's just GDK_SURFACE_TOPLEVEL there, no need for a type check)
3) Have a separate case for GDK_SURFACE_POPUP and ensure that
it doesn't get WS_CHILDWINDOW (and neither should GDK_SURFACE_TEMP).
There is no need for popups to connect to the frame
clock to pause and unpause events on the display -
the toplevel already does it.
And don't connect to paint either - handle paint
on popups recursively.
Somewhat change the order of initialization (to be closer
to what Wayland backend does).
Also remove the wrapper field that is no longer needed -
it used to hold a pointer to the main GdkWindow instance,
which wrapped GdkWin32ImplWindow. Since impls are gone,
nothing is wrapping anything anymore.
Fix a substitution error, where wrong pointer was added
to the hash table. Added a comment to ensure that future readers
(including myself) won't be confused by the fact that we're
inserting a pointer instead of the handle itself.
Since we are now sharing frame clocks with multiple
surfaces, we can no longer dispose them unconditionally
when a surface goes away. Only do it if we are a
toplevel (without parent).
This was showing up as criticals on exit when opening
and closing any popover in widget factory.
Now that popups share the frame clock of their
parent, we have to be much more careful about
freezing the clock, since that may stop updates
for another surface.
This commit makes two changes that make the
X11 handling of the frame clock more similar
to the Wayland backend:
- Use gdk_surface_freeze_updates instead of
gdk_surface_freeze_toplevel_updates to avoid
affecting the frame clock
- Bail out early in before_paint/after_paint
if the surface is frozen, to avoid affecting
the frame clock
Together, these two make the X11 popup surface
type work without freezing updates for the toplevel.
With separate clocks, the phases are not coordinated,
which messes with GTKs size allocation machinery treating
the entire widget tree as a whole, and causes us to
run into assertion where popups get drawn before they
are allocated.