GitLab

This adds specific marshallers for all of the locations where a generic
marshaller is being used. It also provides va_marshallers to reduce the
chances that we get stack traces from perf going through ffi_call_unix64.

This is forward ported from gtk-3-24.

# Conflicts:
#	gtk/gtkeventcontrollerkey.c
#	gtk/gtkeventcontrollermotion.c
#	gtk/gtkgesture.c
#	gtk/gtkgesturemultipress.c

GL_LINEAR doesn't use mipmaps, so don't generate them.

GskTransform can do this for us now.

These functions return the new transform so their return value should
really never be ignored.

We don't need to just look at the scale of the new modelview matrix, but
at the one we get when multiplying the new one with the current one.

Test case attached.

for the modelview matrix. We need this later.

Test case attached.

Fixes #1920

Move private api into a private header.

Remove comments that are old enough to still
talk about option menus and item factories.

GDK W32: Ensure correct stacking of popup windows (GTK4)

See merge request !902

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.

No use of GtkArrowPlacement anywhere.

Drop global coordinates

See merge request !899

The menu shell is not a direct parent anymore.

The menu shell is no longer the direct
parent of menu items.

Now that menubar and menu are containers
with internal structure, we need to be
careful about doing the right thing in
forall and dispose.

Convert dialog

See merge request !898

Left/Right arrow now work again to enter
or leave a submenu.

Home, End, Page Up/Down, work again.

This gets us most of the way to working scrolling.

Make GtkMenuBar use a box as well,
and let GtkMenuShell get the items
from GtkMenuBar and GtkMenu via
a vfunc. Use that to fix the keynav
implementation in GtkMenuShell.

This brings back some support for scrolling.
We still need to reinstate some of the
scroll-to-selected and keynav functionality.

This makes some of the GtkMenuShell api
no longer work, since we don't let the
menu shell code maintain the list of
children anymore.

Nothing should use them anymore.

It seems we want local coords here anyway.

This commit removes support for scrolling and
for the keep-up triangle from GtkMenu, and gets
rid of all use of global coordinates.

Benjamin Otte authored Apr 25, 2019 and Matthias Clasen committed May 31, 2019

No need to do complicated math when we can just look at the allocation.

Benjamin Otte authored Apr 21, 2019 and Matthias Clasen committed May 31, 2019

Returns the parent menu shell or NULL.

Replace all calls to gtk_widget_get_parent() with this function.

Lubomir Rintel authored May 30, 2019 and Matthias Clasen committed May 31, 2019

Changes

  <object class="GtkDialog">
    <child internal-child="vbox">
      <...>
        <child internal-child="action_area">...</child>
        ...
      </...>
      <packing />
    </child>
  <object>

to

  <object class="GtkDialog">
    <child internal-child="content_area">
      <...>
        ...
      </...>
    </child>
    <child internal-child="action_area">...</child>
  <object>

Overlay scrolling setting

See merge request !873

If the gtk-overlay-scrolling setting is FALSE,
don't use overlay scrollbars.