We can use gdk_window_peek_children here, instead of copying
the list. Note that we preserve the bottom-to-top ordering by
iterating the list from the end.
gdk_window_get_children_with_user_data was doing a list
reversal while filtering the list.
The string we were using is the representation of the internal text
in the popover entry. However that can be freed before setting the
bookmark label, if i.e. the row is destroyed and therefore the popover
as well.
To avoid that, duplicate the label in a local variable.
One of the consequences is that for those people using development version
we migth screwed its bookmarks file, since the bookmark manager wrote
garbage from the already freed label.
https://bugzilla.gnome.org/show_bug.cgi?id=755215
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.
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.
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
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.
Traditionally a sequence is set to GTK_EVENT_SEQUENCE_DENIED state when
it is to be ignored, which means it is dormant, but still managed by the
gesture (accounting, "denied" sequences still make "slots" in multitouch
gesture busy, etc...).
This gesture will run for all button presses and releases in the window
though when presses happen on the "window content" region, and we can't
account for every children to be as educated as setting the proper mask
on every window, or ensuring events will be propagated as they should.
In order to cater for this, just reset the gestures, we can live without
such accounting in these specific GtkGestureSingle gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
Instead of using a fixed size, use a factor of the surface size. This
helps in situations where animations of surrounding widgets are used
and cause a rapid rate of surface destroy/create cycles.
It makes no sense to skip denied sequences here, the gestures are
still carrying out the accounting for these, which must be also put
to an end if we're possibly not receiving any further events from
this sequence.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
At the time event_check_cancel_sequence_on_hierarchy() is called, the widget
has been already unparented. Given the widget itself is being destroyed,
cancellation on it is impending in one way or another, we still must
propagate cancellation across all parents, so retrieve it early before
possible widget destruction.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
Otherwise it's attempted through a timeout, which gets cancelled early after,
and the slider disappears after a while with no mouse activity despite the
ongoing implicit grab.
Once the grab is finished, check_update_scrollbar_proximity() will be called
again on both scrollbars, and the fade out animation will be triggered as a
result.
https://bugzilla.gnome.org/show_bug.cgi?id=754745
When right-clicking in an empty folder, you should get a context
menu, not a crash. The code for positioning the popover was not
handling the eventuality of no row under the pointer. Just position
the popover right at the click location in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=755021
A lot of time was spend rendering the shadows on windows with CSD, in
particular the corner pieces, since they are the largest parts. This
patch catches this particular case and caches the pre-rendered blur
masks.
This makes the shadow code go from 25% to 8% of the time when resizing
gtk3-demo.
