Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.

This way, we get a special no-copy case for resources.

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

This function does bad things, and is not an
API that we want to take into GTK+ 4.

If this is a problem, it needs to be handled explicitly.

Avoid the ugly priv->tool_box==NULL check in ::add (and ::remove) by
just not using template xml for this small class. Also, make sure the
GtkBin child is properly set and implement remove to also properly
remove it. Remove the manual widget margins and add some CSS for it.
Also switch to simply using a GtkCenterBox.

Since the GtkSearchBar is not the direct parent, we need to remove them
properly from priv->box_center.

both box_left and box_right are unused.

and the build.

We only use the widget pointer here once.

According to meson it's the only private header that doesn't conform to
the *private.h naming.

Fix that.

GdkContentFormatsBuilder is currently not introspectable, as it does not
have a GType. We can turn it into a boxed type, but we need to implement
memory management for it.

The current gdk_content_formats_builder_free() function returns a newly
constructed value, so we cannot use it as a GBoxedFreeFunc; additionally
copying a GdkContentFormatsBuilder contents would make it a bit odd, as
you could get multiple identical GdkContentFormats out of the copies.

A simple approach is to model the GdkContentFormatsBuilder API to follow
the GBytes one: use reference counting for memory management, and have
a function to release a reference, return a GdkContentFormats, and reset
the GdkContentFormatsBuilder state.

For language bindings, we can provide a get_formats() function that
returns the GdkContentFormats instance and resets the builder instance,
leaving the reference count untouched.

For C convenience we can keep gdk_content_formats_builder_free(), and
make it a wrapper around gdk_content_formats_builder_get_formats(), with
the guarantee that it'll free the builder instance regardless of its
current reference count.

https://bugzilla.gnome.org/show_bug.cgi?id=793097
https://blogs.gnome.org/otte/2018/02/03/builders/

No need to check for the event type here.

As discussed.

The result won't be visible anyway. This also prevents problems with
widgets that create some resource the size of the widget, like
GtkGLArea. It also keeps us from snapshotting revealers with
size 0.

GDK has a lock to mark critical sections inside the backends.
Additionally, code that would re-enter into the GTK main loop was
supposed to hold the lock.

Back in the Good Old Days™ this was guaranteed to kind of work only on
the X11 backend, and would cause a neat explosion on any other GDK
backend.

During GTK+ 3.x we deprecated the API to enter and leave the critical
sections, and now we can remove all the internal uses of the lock, since
external API that uses GTK+ 4.x won't be able to hold the GDK lock.

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

The main GDK thread lock is not portable and deprecated.

The only reason why gdk_threads_add_timeout() and
gdk_threads_add_timeout_full() exist is to allow invoking a callback
with the GDK lock held, in case 3rd party libraries still use the
deprecated gdk_threads_enter()/gdk_threads_leave() API.

Since we're removing the GDK lock, and we're releasing a new major API,
such code cannot exist any more; this means we can use the GLib API for
installing timeout callbacks.

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

The main GDK thread lock is not portable and deprecated.

The only reason why gdk_threads_add_idle() and
gdk_threads_add_idle_full() exist is to allow invoking a callback with
the GDK lock held, in case 3rd party libraries still use the deprecated
gdk_threads_enter()/gdk_threads_leave() API.

Since we're removing the GDK lock, and we're releasing a new major API,
such code cannot exist any more; this means we can use the GLib API for
installing idle callbacks.

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

The widget was basically unmaintained since GTK 3.0 and the only known
user was Glade.

It's not used any more, recent files are only used by the filtchooser
and that one uses GtkRecentManager directly.

Follow the naming policy for private headers.

Follow the naming scheme for private headers.

We need to have two lists: one, with the list of sources that need to be
introspected; and one with the list of sources that contain only private
symbols.

This reduces the amount of source files that the introspection scanner
needs to traverse, and thus the build time.

The places sidebar is not a publicly documented API, so there's no need
to use a gtk-doc stanza — especially if the syntax of the stanza is
wrong.

There's no need to do that any more, as only explicitly annotated
symbols are exported.

Follow the same convention for private headers as newer parts of GTK.

The gtkiconcache.h header is private, so rename it to follow the naming
scheme for private headers.

Be a good GObject citizen and use G_DECLARE_FINAL_TYPE instead of
writing the usual GObject boilerplate.

After commit ffef28a7,
gtk-icon-browser was spewing critical warnings when
changing sections. Avoid that by respecting the return
value of gtk_tree_model_get_iter.

This reverts commit a29306cb.

The slider gets its new size in size-allocate, so we have to do this
even if the range has no origin.

GN authored Jan 23, 2018 and Emmanuele Bassi committed Jan 28, 2018

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

Otherwise, overridden pick vfuncs don't work and we e.g. pick widgets
scrolled away in a viewport.

No need to keep a separate current_event variable around, we don't use
it anyway.

We can use the existing ::event handler for this.

GtkGesture is a GtkEventController. gtk_event_controller_dispose() calls
_gtk_widget_remove_controller(). That NULLs the pointer-to-Controller in
our EventControllerData but does not delete said ECData from our GList.

Subsequently, if that same Widget gets unparent()ed, that method calls
unset_state_flags(), which leads to doing reset_controllers() if we are
insensitive. Now, unlike most most other loops over the GList of ECData,
reset_controllers() does not skip nodes whose pointer-to-Controller is
NULL. So, we call gtk_event_controller_reset(NULL) and get a CRITICAL.

This surfaced in a gtkmm program. The Gesture is destroyed before the
Widget. The Widget then gets dispose()d, which calls unparent()… boom.
I didn’t find an MCVE yet but would hope this logic is correct anyway:

The simplest fix is to make the loop in gtk_widget_reset_controllers()
skip GList nodes with a NULL Controller pointer, like most other such
loops, so we avoid passing the NULL to gtk_event_controller_reset().

In other, live cases, _gtk_widget_run_controllers() loops over the GList
and removes/frees nodes having NULL Controllers, so that should suffice.
But this clearly was not getting a chance to happen in the failing case.

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

Juan Pablo Ugarte authored Jan 22, 2018 and Carlos Garnacho committed Jan 22, 2018

Fix bug 771986 "Inconsistent 'row-activated' signal emission before \
drag'n'drop, 'activate-on-single-click'=TRUE, 'reorderable'=TRUE"

We only use the graphene_rect_t version of the offset_clip for the
fallback cairo nodes.

Otherwise, gtk_widget_get_window returns NULL and we can't successfully
perform a grab via the later gdk_set_grab call. This fixes the entry
completion in the file chooser not working.