wayland: Rewrite Cairo rendering

Also, split it into its own file - which was the original reason for
looking at this code, the rewrite was an unintentional side effect.

This changes the context to create surfaces on demand.
So whenever the compositor holds onto a surface while GDK wants to
render, it just creates a new surface. If the compositor releases
surfaces, we will retain one for the next frame to be rendered, but free
all extra ones.
This way, we should get to a stage where we have exactly as many
surfaces as needed and never allocate/free any.

x11: Move implementation of Cairo context backends

Also, don't implement SurfaceClass.ref_cairo_surface() anymore. This
means calls to it will crash now. But as they only happen in the generic
GdkCairoContext implementation, we shouldn't be affected by that.

Plus, once all backends have been ported, that call is going away
anyway.

surface: Merge function into only caller

gdk: Remove GDK_DEBUG=cairo-image

This is the default now - at least until cairo rendering gets split
into backends.

surface: Fold function into only user

cairocontext: Turn cairo_create() function into a vfunc

gdk: Remove unused GL setting

gdk: Add Cairo context implementations for all backends

And make the GdkCairoContext as abstract.

The idea of this and thje following commits is to get rid of all
Cairo code in gdksurface.c (and $backend/gdksurface-$backend.c)
by moving that code into the Cairo context files.
In particular, the GdkSurfaceClass.begin_frame/end_frame()
functions (which are currently exclusively used by the Cairo code
should end up being moved to GdkDrawContextClass.begin/end_frame().

This has multiple benefits:

1. It unifies code between the different drawing contexts.
   GL lives in GLContext, Vulkan in VulkanContext and Cairo in
   CairoContext. In turn, this makes it way easier to reason about
   what's going on in surface-specific code. Currently pretty much
   all backends do things wrong when they want to sync to drawing
   or to the frame clock.

2. It makes the API of GdkSurface smaller. No drawing code (apart
   from creating the contexts) needs to remain.

3. It confines Cairo to the Drawcontext, thereby making it way
   more obvious when backends are still using it in situations
   where it may now conflict with OpenGL (like when doing the dnd
   failed animation or in the APIs that I'm removing in this
   branch).

4. We have 2 very different types of Cairo contexts: The X/win32
   model, where we have a natively supported Cairo backend but do
   double buffering ourselves and use similar surfaces and the
   Wayland/Broadway model where we use image surfaces without any
   Cairo backend support and have to submit the buffers manually.
   By not sharing code between those 2 versions, we can make the
   actual code way smaller. We also get around the need to create
   1x1 image surfaces in the Wayland backend where we pretend
   there's a native Cairo surface.

cairocontext: Move a function

A function of GdkDrawingContext is only used when drawing with Cairo, so
move it to GdkCairoContext.

gdk: Move Cairo code from surface to CairoContext

This just moves code, no actual changes to functionality are happening.

gdk: Add GdkCairoContext

This does nothing but disallow passing NULL to gdk_surface_begin_paint()
and instead require this context.

The ultimate goal is to split out Cairo drawing into its own source file
so it doesn't clutter up the generic rendering path.

gtk-demo: Merge widgetbowl into fishbowl

demo: Clean up GtkFishbowl widget

1. Remove set_icons property
2. Make it a GtkWidget subclass
3. Add gtk_fishbowl_set_creation_func()
4. Make the widgetbowl use the new benchmarking infrastructure of the
   fishbowl

demo: Move benchmarking implementation to fishbowl widget

Update Esperanto translation

testentrycompletion: Use the model we already got

cherry-pick of gtk-3-22 commit af350b20b1c396ec55ca6a71eab23fdca6ffb784

Update Russian translation

snapshot: Get rid of record_nodes flag

Instead, use GTK_DEBUG=snapshot for it.

rendernode: Remove gsk_render_node_set_name()

And of course, gsk_render_node_get_name() is gone, too.
The replacement is of course debug nodes.

As a side effect, GskRenderNode is now *really* immutable.

snapshot: Redo debug messages

Instead of every snapshot function having debug messages, have an
explicit gtk_snapshot_push_debug() function that appends a debug node.

gsk: Add GskDebugNode

Merge branch 'wip/matthiasc/emoji-picker' into 'master'

Wip/matthiasc/emoji picker

See merge request GNOME/gtk!115

Drop Ctrl-Shift-e support

Now that we have Emoji completion, drop the rather limited
Ctrl-Shift-e support in GtkIMContextSimple, and leave this
sequence to input methods.

widget-factory: add emoji completion to an entry

entry: Add emoji completion

Pop up completions when the text in the entry matches :word:
This functionality has to be enabled using the enable-emoji-completion
property.

Add an emoji completion popup

This widget provides entry completion-like functionality
for Emoji codes like :grin: or :kiss:.

Export some entry functions privately

This will be used in the following commits.

wayland: Allow a NULL inhibitors hash table

The shortcuts inhibitors hash table is created when we create a
GdkWaylandWindow implementation for a GdkWindow, and it's destroyed once
we finalize the instance. The fake "root" window we create for the
Wayland display does not have a backing native window, so the shortcuts
inhibitors hash table is set to NULL; this causes a critical error
message when calling g_hash_table_destroy() on it. The finalization of
the root window happens when we close a display connection.

We should use g_clear_pointer(), instead, as it's NULL safe.

Without this change, the displayclose test fails, as all warnings are
considered fatal.

gtk-demo, testgtk: Don't pass an integer to fabs

It looks like a mistake which compilers are likely to warn.

imcontextxim: Don't assign a variable to itself

This causes clang to show warnings.

Fix header guards

They were found by clang.

build: Use cc.links to check linker arguments

Instead of hard-coding linker flags for a specific operating system and
a specific compiler, we can should cc.links to test them, so they can be
used on more operating systems and compilers.

build: Make the default setting work on non-Linux Unix-like systems

All of the four platform-dependent backends are enabled by default. It
is usually a good default because it requires users to explicitly choose
backends they want to use. Rules in meson.build also automatically
disable unavailable backends for macOS, Windows, Linux, so users on
these 3 major platforms don't have to manually disable things when
running meson commands.

However, meson.build doesn't do the same thing for other Unix-like
systems, which is acceptable but not ideal. To make it easier to build
GTK+ on these systems, the Linux case, which enables X11 and Wayland and
disables Win32 and Quartz, is made the default for all operating systems
that are not Windows or macOS.

This commit also changes most 'host_machine.system()' calls to os_*
variables, which are easier to read and less likely to be used wrongly.

Update Spanish translation

wayland: Allow a NULL inhibitors hash table

The shortcuts inhibitors hash table is created when we create a
GdkWaylandWindow implementation for a GdkWindow, and it's destroyed once
we finalize the instance. The fake "root" window we create for the
Wayland display does not have a backing native window, so the shortcuts
inhibitors hash table is set to NULL; this causes a critical error
message when calling g_hash_table_destroy() on it. The finalization of
the root window happens when we close a display connection.

We should use g_clear_pointer(), instead, as it's NULL safe.

Without this change, the displayclose test fails, as all warnings are
considered fatal.

Merge branch 'wip/lantw/improve-freebsd-build-and-fix-warnings' into 'master'

Improve meson.build for FreeBSD and reduce the number of warnings during compilation

See merge request GNOME/gtk!123

Widget: Add missing space in new warning

themes: Fix a new comment

bah.

themes: Fix swapped borders on RTL PathBar buttons

.linked assumes the container is a GtkBox, which is documented as never
flipping children in RTL, so :first-child is always the left child, etc.
GtkBox does that by reordering its CSS nodes when the direction changes.

But most widgets don’t do that, so :first|last-child are 1st/last ADDED
and swap sides in RTL. GtkPathBar is so, and ignoring that in our themes
meant that in RTL, its left/right buttons got each other’s borders. Yuk!

This patch adds the groundwork for supporting widgets like that, via the
%linked_flippable placeholder, and applies that to override buttons in
  filechooser .path-bar.linked > button
so that the correct borders get applied to those buttons when using RTL.

Note that I select only PathBars within a FileChooser because we also
have NautilusPathBar, which also uses widget.path-bar – but *does* flip
its nodes for RTL already, so letting that get affected broke it again!

https://bugzilla.gnome.org/show_bug.cgi?id=772817

CheckMenuItem: Fix insert_after|before() here too

See the previous commit.

There may be other cases of these being swapped by Gadget conversions,
but hopefully someone else will find and fix those before I have to…

Close https://gitlab.gnome.org/GNOME/gtk/issues/200

MenuItem: Fix broken args to insert_before|after()

The widget & its parent were swapped to each other’s place in the calls.

https://gitlab.gnome.org/GNOME/gtk/issues/200

Widget: Show widget name/addrs if fail to reparent

so we can more easily get an idea of where the problematic code is

https://gitlab.gnome.org/GNOME/gtk/issues/200

Widget: Trivially fix arg name in non-doc comment

MenuButton: popover connects to menu_deactivate_cb

This was missed (even before my recent patches).

https://gitlab.gnome.org/GNOME/gtk/issues/199

MenuButton: Disconnect newly added signal handler

Otherwise, we do stuff we shouldn't, as the failing pipeline showed:
https://gitlab.gnome.org/GNOME/gtk/pipelines/9431

https://gitlab.gnome.org/GNOME/gtk/issues/199

MenuButton: Clarify NULL popup/over/menu/model doc

MenuButton: Drop ref to Popover on its ::destroy

Otherwise, if the Popover is destroyed before the MenuButton, the latter
still had a non-NULL but invalid instance and tried to use it in dispose

Close https://gitlab.gnome.org/GNOME/gtk/issues/199

Entry: Show optional style classes in node diagram

a11y/ScrolledWin|IconView: Connect signals safely

Use g_signal_connect_data() instead of g_signal_connect_object()
to make sure the callback gets disconnected when the data object
is destroyed. This avoids problems in garbage-collected bindings.

https://bugzilla.gnome.org/show_bug.cgi?id=789215

Update Polish translation

gtk-demo, testgtk: Don't pass an integer to fabs

It looks like a mistake which compilers are likely to warn.

imcontextxim: Don't assign a variable to itself

This causes clang to show warnings.

Fix header guards

They were found by clang.

build: Use cc.links to check linker arguments

Instead of hard-coding linker flags for a specific operating system and
a specific compiler, we can should cc.links to test them, so they can be
used on more operating systems and compilers.

build: Make the default setting work on non-Linux Unix-like systems

All of the four platform-dependent backends are enabled by default. It
is usually a good default because it requires users to explicitly choose
backends they want to use. Rules in meson.build also automatically
disable unavailable backends for macOS, Windows, Linux, so users on
these 3 major platforms don't have to manually disable things when
running meson commands.

However, meson.build doesn't do the same thing for other Unix-like
systems, which is acceptable but not ideal. To make it easier to build
GTK+ on these systems, the Linux case, which enables X11 and Wayland and
disables Win32 and Quartz, is made the default for all operating systems
that are not Windows or macOS.

This commit also changes most 'host_machine.system()' calls to os_*
variables, which are easier to read and less likely to be used wrongly.

widget: Position changes don't require a redraw

Well, they don't require a redraw of the widget, because the widget
itself didn't change.
They require a redraw of the parent, because that now displays the
widget in a different position.

And this means we can keep the cache of the widget's render node.

My fishbowl numbers are through the roof^W water surface. Vulkan gets
4000 now.

demo: Don't add more icons all the time

If adding new icons takes longer than a second, the frame clock should
run before we add even more icons...

build: Remove 'name' kwarg from has_function calls

They cause warnings with later meson versions.

build: Fix copy/paste error

Always use #ifdef for G_ENABLE_DEBUG

Release builds don't define it to 0, they just don't define it. Avoid
the compilation warning we get otherwise.

sizerequestcache: Directly initialize some locals

Declaring them and initializing them in the same block of code without
an empty line in between is really just confusing.

Use inlined gtk_widget_get_display version in a few places

We can safely do this whenever we already made sure that the given
pointer is a valid GtkWidget.

widget: Add static inline version of gtk_widget_display()

Due to the few type checks in gtk_widget_get_display(), it was the
slowest part of a call to gtk_widget_query_size_for_orientation if the
in case of a cache hit.

textview: Remove handling_key_event flag

It's not used anymore.

gsk: Make gsk_text_node_new_with_bounds private

We pulled out the bounds calculation for performance reasons, but the
caller can't know how to properly compute them. Inside gtk+, we can do
that but it's not good enough for public API.

gl renderer: Rename texture_id parameter to fbo_id

So this makes sense again.

widget: Use get_instance_private more often

To be more consistent with newer code. We can also save a few lines here
and there by pulling the priv initialization before the precondition
checks.

sizerequestcache: Constify some locals

Make it clear that we only use them for lookups here.

sizerequestcache: Use int instead of gint

sizerequest: Pull locals in closest scope

snapshot: Fix some documentation problems

viewport: Remove useless import

Just a debugging remnant

viewport: Remove outdated comment

gl renderer: Fix fallback node scaling

Merge branch 'print-deserialize' into 'master'

printing: Be more careful when deserializing

See merge request GNOME/gtk!121

printing: Be more careful when deserializing

The GVariant we are getting here might not be coming
from GTK+, but rather from some other source. Best to
be forgiving and deal with missing data without crashing.

This was causing the GTK+ portal backends to crash on
print requests from Qt.

Updated Spanish translation

Revert "Update Spanish translation"

This reverts commit 8570d33e08a72abf9004a92784663a3aeba86c00.

stack: protect set_visible_child_name from NULL stack

Return with error if gtk_stack_set_visible_child_name is called
with NULL parameter

(cherry picked from commit 2ee5aee4a9f01cce3dda7dff877070b62c3e2880)

Merge branch 'gtkplacesview-finalization-fixes-master' into 'master'

Gtkplacesview finalization fixes

See merge request GNOME/gtk!119

gtkplacesview: disconnect from server list monitor changes on destroy

It might happen otherwise that a change is recorded in between the
widget dispose and finalization, causing a crash when setting
the visible name for the GtkStack (as that will be NULL at that point)

gtkplacesview: unset entry_pulse_timeout_id before removing it

Fixes a warning on widget finalize, when trying to remove an invalid
source.

Scale: Document new optional classes on value node

Range: Make down/up keys act like down/up scrolls

Before now, down/up keys on H Ranges would increase/decrease value resp,
which is unintuitive & worse, contradicts what we already do for scrolls

Fix simply by moving to the new should_invert_move() as scrolls just did
– which also gets us the other benefits explained in the last 2 commits.

https://bugzilla.gnome.org/show_bug.cgi?id=407242
https://bugzilla.gnome.org/show_bug.cgi?id=791802

Range: Use should_invert_move() to scroll value

This fixes RTL and/or :inverted Ranges responding to a horizontal scroll
by moving the value/slider button in the opposite direction... See prev.

https://bugzilla.gnome.org/show_bug.cgi?id=791802

Range: Add should_invert_move() for scrolls & keys

This will be used in subsequent commits to fix the sign by which the
value is changed in response to directional scroll or keypress events.

The idea is: you have a movement to make – in the form of a delta that
follows widget directions, i.e. −1 means left or up, +1 means right or
down – and you want to know whether that delta needs to be inverted in
order to produce the intuitively expected directional change of :value.

The existing should_invert() is not sufficient: it just determines
whether to invert visually, but we need more nuance than that for input.

To answer that – while not doubling up the work for scrolls and keys – I
add a helper should_invert_move(), which considers other relevant state:

 • A parallel movement on priv->orientation should just use the existing
   should_invert(), which already worked OK for this case (not others).

 • Movements on the other orientation now depend on priv->orientation:

    ◦ For a horizontal Range, always invert, so up (i.e. −ve in terms of
      widget coords) always means increase value & vice-versa. This was
      done in get_wheel_delta(), but move it here for use with keys too.

    ◦ For a vertical Range, ignore :invert as it’s only relevant to the
      parallel orientation. Do not care about text direction here either
      as RTL locales do not invert number lines, Cartesian plots, etc.

This returns TRUE if the delta should be inverted before applying to the
value, and we can now use this function in both scroll and key handlers.

https://bugzilla.gnome.org/show_bug.cgi?id=407242
https://bugzilla.gnome.org/show_bug.cgi?id=791802

snapshot: Don't handle clip anymore

If widgets want to clip things, they now need to do it themselves.

By not taking care of clip, we avoid the need to track clip. And by not
tracking clip, we can avoid all unnecessary cache invalidations that we
were doing for render nodes whenever the clip changed.

And when you are scrolling, the clip changes *a lot*.

MenuShell: Avoid compiler warning re un/signed cmp

priv->button is a guint, but we assigned it to a local gint.

gtk/gtkmenushell.c:734:37: warning: comparison between signed and
  unsigned integer expressions [-Wsign-compare]
           if (button && (new_button != button) && priv->parent_menu_shell)
                                     ^

Menu|Item: Fix FIXME re non-const interned strings

These are members of the private struct, so it hurts no one to fix this.

Menu: Remove redundant typecheck in private func

Everything that calls this already ensured we are a valid GtkMenu.

Menu: Update @accel_path annotation/description

Menu: Typecheck AccelGroup passed via public API

Menu: Typecheck before dereferencing to get ->priv

MenuShell: Sanitise take_focus bool via public API

We store in priv then compare it later, so better make sure it’s 0 or 1.

MenuShell: Typecheck the instance @ select_first()

since this is public API and therefore might get junk passed to it.

CellRenderer: Link to CellEditable.start_editing()

...from CellRenderer::start-editing, to point people in the direction of
info about the lifecycle of the Editable and how to do generic setup.

https://gitlab.gnome.org/GNOME/gtk/issues/154

CellRenderer: Clarify doc of .start_editing()

Drop the line copied from .activate(), replace it with a description of
what this method actually does, and explain what a NULL result means.

https://gitlab.gnome.org/GNOME/gtk/issues/154

CellRenderer: Entry is not the only CellEditable

so link to GtkCellEditable and note that GtkEntry is just one example.

CellRenderer|Editable: Don't @See_also subclasses

The documentation knows that from the inheritance hierarchy, without us
having to manually duplicate that info here. Link to each other instead.

CellEditable: Clarify doc on lifecycle of editable

* Note in the intro that we're really thinking about temporary widgets
* Mention a gotcha regarding GtkEntry and how ::focus-out stops editing
* Give some examples of what you'd want to do in ::editing-done
* Be a bit more precise about what ::remove-widget represents
* Summarise the lifecycle between Renderer/Editable in .start_editing()
* Emphasise again there that this should be viewed as a temporary widget

https://gitlab.gnome.org/GNOME/gtk/issues/154