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.
This is a backport of the GdkProfiler from master. It does not include
the pixel bandwidth numbers that come from gdkdrawcontext.c since there
does not seem to be an analog in 3.x.
Additionally, this implements the recent changes for SYsprof's D-Bus
profiler API which adds a Capabilities property and an options hash-table
to the D-Bus interface for forward portability.
We don't need to cover every case with a va_marshaller, but there are a
number of them that are useful because they will often only be connected
to by a single signal handler.
Generally speaking, if I opened into a file to add a va_marshaller, I just
set all of them.
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.
Similar to previous removals of g_cclosure_marshal_VOID__VOID we can remove
other marshallers for which are a simple G_TYPE_NONE with single parameter.
In those cases, GLib will setup both a c_marshaller and va_marshaller for
us. Before this commit, we would not get a va_marshaller because the
c_marshaller is set.
Related to GNOME/Initiatives#10
If we set c_marshaller manually, then g_signal_newv() will not setup a
va_marshaller for us. However, if we provide c_marshaller as NULL, it will
setup both the c_marshaller (to g_cclosure_marshal_VOID__VOID) and
va_marshaller (to g_cclosure_marshal_VOID__VOIDv) for us.
This has caused numerous issues for users, especially in the
filechooser, which have not been fixed in all the years since the pixel
cache has been introduced.
If anyone seriously has complaints about the treeview performance (and
those did not exist with the pixel cache), feel free to revert this
commit *and* fix the pixel cache issues.
Closes#503Closes#1691Closes#466
It takes half a second on my system to initially
populate the Emoji chooser. That is too long. Do
the work in 8 millisecond chunks to give GTK a
chance to get some frames done.
If the cursor coordinates are outside of the content (the GtkRBTree),
gtk_tree_view_bin_draw() will return and not draw the rubber band
rectangle.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1859
This resulted in -DINCLUDE_IM_ti-et getting passed to gcc resulting in
lots of warnings. Use underscorify() so we get the correct -DINCLUDE_IM_ti_et instead.
We also need to ensure that we pass in -DINCLUDE_IM_xxxx when building
the GTK DLL/.so, in addition to building the respective (static)
immodules, so that we did really link in the immodules into the final
GTK DLL/.so.
Make it a yes/no/auto combo. "yes" means all modules are built into libgtk,
"no" that none are and "auto" uses the platform defaults, yes on win32,
no otherwise.
If we need more we can always extend it later.
Various adjustments to make the config.h output between autotools
and meson more similar by testing on Linux and Windows/MSYS2.
Setting things to 1 instead of true and shifting things around is motivated
by reducing the diff between the generated files.
This changes the configure option into two states:
auto: build all that can be build (default)
A list of backend names: build them and fail if we can't
"papi" is missing because it's not in Debian and I can't test it.
The autotools build uses relative filenames here while with meson
we get absolute paths. Switch to basename so we get the same result
for both and don't break reproducible builds with absolute paths
in public headers.
Build the input modules for GTK+, either as modules or built directly
into GTK. Also provide a configure option to build the specified
immodules, or all, or the backend immodule(s) or none of the immodules
into GTK. Note that for Visual Studio all immodules are built into
the GTK DLL by default, like what is done in the Visual Studio projects.
Note that building the backend immodules for Quartz, X11 and Wayland are
currently untested.
This will ensure that the version info is easily visible from the
GDK/GTK+ DLLs, and ensure that the print dialogs will have a more modern
look and feel.
