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
Use the scripts that we have to copy the 2010 projects and updating
the various items in the project files to make them Visual Studio
2019-compatible upon 'make dist'.
Also ensure that the introspection NMake Makefiles can properly detect
that we are building with Visual Studio 2019.
From the Meson port, gtk/gtktesteutils.c now includes
gtk/gtktypefuncs.in instead of gtk/gtktypefuncs.c, so we should do the
same thing in the Visual Studio projects, to fix the build.
Also, since build/win32/gentypefuncs.py is an adaptation of the script
from GTK master (in gtk/), and that we now have gtk/gentypefuncs.py, we
should use the version of the script in gtk/ and drop the one in
build/win32.
Currently, calling `gtk_entry_completion_complete()` does not adjust
the visbility of the popup used to show completion entries. This makes
it difficlt to dynamically populate the model based on what is being
entered into the completion's entry.
For example, if the model is being populated from a database, and no
matches have (yet) been added between typing a character and the 100ms
delay before completion is automatically triggered, the popup will not
be shown even after matches have been added.
This patch simply moves the related code from the private timeout method
to the public function and shuffles the position of some functions so as
to keep the compiler happy.
In 9236ee0564 the cups code was updated to use newer API with cups >= 2
and a later commit (a7e207abe) dropped the old code paths and added version
checks in meson/autotools.
The newly used functions were httpConnect2 and httpReconnect2 which are
available since 1.7 and don't require cups 2.0.
Change the versions checks to 1.7 instead so gtk can still be build with
older cups (macOS 10.9 for example, see #1950)
httpGetAuthString() was added with cups 1.3 and we depend on a newer version
now. The direct field access was a fallback in case httpGetAuthString()
was missing, so this can also be dropped.
--api-version returns 1.6 with cups 2.1.0 which breaks the build on
older macOS.
Looking at the upstream git history the value is hardcoded and only randomly
updated as part of cleanup commits, so it looks like it shouldn't be used.
Just use --version instead which gives us the real cups version.