Visual Studio does not support things like -Wl,export-dynamic, so we
need to export those symbols by using __declspec(dllexport). So, we
decorate these with macros which we define accordingly for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=785210
It's getting harder and harder to find a dummy style property to use
here, so remove the test case since style properties should be going
away soon anyway.
Previously, we would request a size of 0×0 when the transition type was
NONE and the child un-revealed, making the revealer in this case a
gtk_widget_set_visible replacement. Instead, to the exact same thing we
do in the CROSSFADE case and request the child size instead. This also
keeps the revealer from under allocating the child when the transition
type is set to NONE.
Events that get to gtk_main_do_event() have the toplevel GdkWindow
as event->any.window. Also, ensure that coordinates fall within
sensible places of the windows, since those might have shadows,
headerbars and whatnot on wayland.
It was only testing the default configuration, where overlay scrolling
is on and both scrollbars use POLICY_AUTOMATIC. We should also test the
other 3 configurations that are available by including non-overlay
scrollbars and/or those that use POLICY_ALWAYS.
https://bugzilla.gnome.org/show_bug.cgi?id=778853
The `-export-dynamic` flag is a libtool-specific flag; since we're not
using libtool with Meson, we should instruct the C compiler to use the
appropriate linker flag instead.
This was only every implemented under X11, and with CSD,
this is clearly in the application realm. We should not
pretend that we can support it on the toolkit level.
https://bugzilla.gnome.org/show_bug.cgi?id=775061
It was only testing the default configuration where overlay-scrolling is
TRUE and the policy is POLICY_AUTOMATIC. We should also test FALSE and
POLICY_ALWAYS. This commit adds those tests and makes the !overlay &&
POLICY_ALWAYS case pass by excluding the size of the relevant scrollbar,
as we are only interested in whether the content size is as requested.
https://bugzilla.gnome.org/show_bug.cgi?id=778853
gboolean ret for whether gtk_text_iter_backward_line() moved the iter
was declared but not used anywhere. I presume it was meant to be
checked, and it passes now, so let’s do it.
gtk_text_iter_backward_line() checks the value of
real->line_char_offset without previously calling
ensure_char_offsets (real) to make sure the former
is up-to-date.
As a consequence of this, when gtk_text_iter_backward_line()
is called after a gtk_text_buffer_insert_range() in the
first line of buffer, the iter is not moved to the start of
the line, and the return value is wrong.
Fixed by adding the ensure_char_offsets() call.
A test case for this bug is added to the textiter gtk testsuite.
These complicate a lot of GdkWindow internals to implement features
that not a lot of apps use, and will be better achieved using gsk.
So, we just drop it all.
Newer versions of Automake warn about forward compatibility when the
build uses sources in sub-directories without the subdir-objects option.
Both GTK+ and GDK have an almost-but-not-quite non-recursive Automake
layout, with sources in sub-directories contributing to the build of a
top-level object.
In theory, just adding subdir-objects to AM_INIT_AUTOMAKE would be
enough, but the test suite references sources in a different top-level
in order to build tests that verify the implementation of private data
structures. This is not really allowed when using subdir-objects and out
of srcdir builds. In order to fix this case, we require some ad hoc
rules to create symbolic links in the appropriate build directory.
