Tooltips tend to be placed on top of a parent surface with a given
relative coordinate, and without any input focus. So lets map them as
subsurfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=756496
Restructure the mapping procedure so that its known up front what the
expected way mapping is to be done (subsurface, popup or stand alone),
and warn if it fails to actually map in such a way (for example a popup
without a parent or device grab, a tooltip without a parent).
https://bugzilla.gnome.org/show_bug.cgi?id=756496
This is a variable holding a ref to an object, so it is
a great case to use g_set_object and g_clear_object.
# Please enter the commit message for your changes. Lines starting
Use CHILD1/CHILD2 instead of 0 and 1, always use the same order and
don't check for child NULL-ness, because it will be done in
gtk_paned_set_child_visible anyways.
Avoid crashes when passing an invalid location to a
gtk_text_buffer_get_iter_at_*() function.
A boolean is returned to know if @iter has been set to the exact
location.
Unit tests are added.
https://bugzilla.gnome.org/show_bug.cgi?id=735341
When the search entry is shown, the 'special' nature of
., ~ and / should not trigger the location entry, because
that interrupts the search and is likely not what the
user intended.
https://bugzilla.gnome.org/show_bug.cgi?id=756505
Disclosure triangles are usually used pointing down, however
in this case the popover spawns in the upper direction, which
makes it odd looking.
Instead of pointing always down or up, point down when not toggled and
animate a rotation when toggled.
https://bugzilla.gnome.org/show_bug.cgi?id=756568
Since the change to use GtkPlacesView we don't want to show
internal storage on the sidebar.
In our case we were checking for drive_can_eject and
drive_is_media_removable.
However for some external hard drives it's reported that they
are not ejectable nor the have removable media. So the only
attribute that they have different from internal drives is that
they can be stopped.
So check for if the drive can be stopped to decide if it is
external or internal.
On the way realized we don't need to check for the mounts associated
with the volume to know if the volume can be ejected or not. So remove
that code.
https://bugzilla.gnome.org/show_bug.cgi?id=756589
It is assumed that border.top is the same than pointing_to.height (which
equals the strong cursor position), which is not since some time ago.
The border calculation has been move on top too, it is now used in the
Y position one, and doesn't depend on anything we calculate later.
Text handles are subsurfaces on wayland, so sort of their own toplevel.
This made gtk_widget_translate_coordinates() to bail out there, resulting
in text handles being mispositioned and jumpy. To fix this, translate to
toplevel GtkWindow coordinates manually, and translate coordinates from
there.
Along the way, the coordinates reported in ::handle-dragged have been
fixed so there is no small jumps in either axis (most noticeable in the
X axis when you started dragging, and in the Y axis when moving between
lines of different heights.
Make it what it is - the enum - so that that it is sure that the hint
will fit in the field. Without this, any hint that doesn't fit in 3
bits will be truncated to the 3 least significant bits, causing
unexpected behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=756496
Using a NULL GAppInfo with g_app_launch_context_get_display() will
generate a critical warning in gio.
Use the display name instead as we don't have any valid GAppInfo to pass
to g_app_launch_context_get_display().
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756439
Otherwise the popopver will be automatically unmapped in
_gtk_popover_update_child_visible() when the X axis (coming more
or less directly from events) goes outside the textview.
GDK_NOTIFY_ANCESTOR would happen when the pointer crosses across a direct
parent/child. However nonlinear events are more likely, specially when
the pointer moves across toplevels (either different apps, or menus being
popped up over the pointer position).
This makes popping up comboboxes and other menus that fall over the pointer
position possible. With the previous detail the GtkMenu code misinterpreted
the crossing event, making it think the button release coming right after
should dismiss the popup, which made menus just flash on the screen unless
you kept the button pressed.
