We are passing widget coordinates to gtk_text_view_window_to_buffer_coords()
which expects coordinates to be relative to the text window in this case.
This may result in drop coordinates being displaced if the side windows to
the top/left sides are visible and taking space, so the DnD indicator will
point to the wrong position.
This can be seen on gnome-builder and gedit when displaying line numbers.
Some distributions (MSYS2, Debian) call autoreconf on a tarball because
they change the autotools artifacts.
In order to rebuild the Broadway generated files, we need to ship the
scripts that we use when disting a release.
The row and rename popovers are always relative_to a row.
We also keep a pointer to them so we can interact with them in
callbacks.
However, if the row is destroyed its associated popovers will be
destroyed as well as relative_to destroyes and frees memory of its
associated widget when its relative_to widget is destroyed.
If we, for example, update the places while the popover is shown we are
going to access and invalid widget on the next time.
To avoid that, connect to the destroy signal of the popovers and clean
the sidebar pointers when that happens.
https://bugzilla.gnome.org/show_bug.cgi?id=755444
The patch did not check for Visual Studio 2008 correctly, plus it
would break the build on later Visual Studio versions, as it should
be __popcnt(), not __popcount(). Fix that.
The popcount builtin was added in GCC after version 4.2 (which is what
some *BSDs are using), which means we need to be more specific when
using it than just asking for GCC.
While we're at it, we can improve the compiler detection, and use a
builtin popcount on Clang ≥ 3.1 and MSVC 2008.
https://bugzilla.gnome.org/show_bug.cgi?id=755455
Instead of handling the horizontal and vertical peers separately
(and often, duplicatively), collect all peers in one go. At the
same time, avoid creating and destroying hash tables more often
than necessary.
The recent changes to build/win32/vs9|10/Makefile.am fixed 'make distclean'
but broke 'make -jN dist', so fix that by listing the *.headers and using
that list as a dependency and to remove those files in one single command
right after we generate the gtk-install.vsprops template, so that we don't
have to worry about them in 'make distclean'.
At the time we populate the model "initially" in constructed(),
it has already been filled and cleared a couple of times (we do
that every time one of the construct properties gets set). So
we can't assume that the model is empty, and have to clear it
first. Otherwise, we add duplicates to the list.
https://bugzilla.gnome.org/show_bug.cgi?id=748080
Plug and Socket require X11 windowing. Often times this is compiled
on systems with both wayland and x11, but not always. Quartz is an
example where it is usually not compiled.
GTK cannot depend on libcanberra-gtk which depends on GTK. This causes
a circular dependency and is especially neat if installed GTK is
different enough from uninstalled GTK.
The default event bubbling paths are prone to just running event controllers
even after the widget was potentially unrealized/destroyed in an event
handler callback, so bail out early if that's the case.
https://bugzilla.gnome.org/show_bug.cgi?id=755352
To GtkGesture machinery, if an event triggers a controller/gesture signal,
and gesture reset/cancellation as a result, the event has been managed
after all.
Commit e3bd895667 effectively changed the return value of the
wrapping gtk_event_controller_handle_event() function, which broke some
paths (eg. gtk_popover_button_press() wouldn't while the GTK+ grab was
active for this reason because the button press event was consumed early
on gtk_window_check_handle_wm_event()).
That patch is not too off-track given potential child widgets' behavior,
we want nonetheless to distinguish the denied vs cancelled paths here
(because GtkWindow itself relies on the GtkGesture behavior described in
the first paragraph on the begin_move/resize paths), so just reset
gestures after the event has already gone through the GtkEventController
so the return value is unaffected.
This updates the Visual Studio Project GUIDs so that they don't repeat with
the GTK+-2.24.x ones, as the 3.x projects can be used with the 2.24.x in a
all-in-one solution file (such as when one wants to use a complete GTK+2
and GTK+3 stack when porting Windows applications from GTK+2 to GTK+3), and
each project in a solution file is expected to have an unique GUID.
