Otherwise we get errors on g_content_type_is_a(). This happens mostly on Windows
because it only knows a limited set of mime types and tries to convert
them to file extensions without any fallback.
We were looking for the cups headers and the cups lib in the default locations
which for example breaks with OpenBSD where the cups headers are under /usr/local/include/
Instead just use the "cups" dependency type from meson which internally uses cups-config.
Fixes#1967
open() in text mode should never be used without an encoding because it defaults
to the locale encoding which is rarely what is wanted.
This fixes the Windows build in some cases (depending on the locale/paths used)
When parsing a UI description for GtkFileFilter we should avoid passing
empty strings, to avoid issues when serialising the filter before
sending it over DBus.
Fixes: #1973
Be prepared for the eventuality that somebody
might reinsert the same action group without
holding any extra references on it.
This was observed as causing crashes in
gnome-builder.
Otherwise the native window gets created with GDK_TYPE_HINT_NORMAL
and in fullscreen appears on its own screen or tab instead of over
the combo like it's supposed to.
The xdg_output interface has a `name` property that reflects the output
name coming from the compositor.
This is the closest thing we can get to a connector name.
Fixes: #1961
The documentation for get_monitor_plug_name() says that we're returning
the name of the connector for the monitor, but we switched it to using
the model name.
The migration from GdkScreen's monitor API to GdkMonitor left out a way
to get the connector's name of a monitor. While there's no real
guarantee that the connector's name is stable, some system components
used it to uniquely identify a monitor until the next plug in/out event.
Since GTK 3 is API stable, we can only add a private setter and getter
functions pair, without a property.
We named the argument `position` in the code and doc arguments, but the
rest of the documentation referred to `index` instead. That was maybe
meant to hint at the child property named :index, but we can simply be
fully clear here. We can call the argument `index_`, replacing the local
variable with that name, thus avoiding any possible confusion with the
unrelated ::get-child-position, and refer users to :index for completion
`index_` is used instead of plain `index` in case anyone is #including
<strings.h> and getting the old index() function superseded by strchr();
see https://gitlab.gnome.org/GNOME/gtk/merge_requests/932#note_531149
Some users expect that the Overlay will automatically request enough
size for its overlay children as well as its main child. It doesn't,
because it's just a GtkBin. Add a short paragraph pointing that out.
Close https://gitlab.gnome.org/GNOME/gtk/issues/1939
The documentation for gtk_widget_get_action_group
and gtk_widget_list_prefixes states that both of
these operate on all the action groups that are
'available' to the widget.
Which means: they are meant to walk up the parent
muxer chain. So do that.
Add tests to verify the expected behavior.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1396
