the drag_begin() vmethod is meant for this, and the internal DnD code
will set up a drag icon if ::drag_begin didn't do so, which means
we are first getting a "default" icon, and then replacing it with the
text surface.
This is completely harmless in X11, but causes issues on wayland as
the DnD icon window is expected to remain unchanged during DnD there.
https://bugzilla.gnome.org/show_bug.cgi?id=748763
The drag destination might be empty, we shouldn't be checking whether
it contains pages at all. Instead, check the source notebook, which
ought to have a selected page if you're dragging something from there.
https://bugzilla.gnome.org/show_bug.cgi?id=749893
gtk_tree_view_set_tooltip_column() specifies that markup in the text
should be escaped.
This fixes critical warnings when hovering over items in the sidebar for
bookmarks that have markup characters in their names.
https://bugzilla.gnome.org/show_bug.cgi?id=719683
The libinput driver will send a 0/0 scroll event on touchpads and other
devices where it knows scrolling stopped for sure. Use these events to
trigger kinetic scrolling from there.
The mechanism is similar to GtkGestureSwipe, we keep a backlog of the
latest dx/dy till a previous point in time, and calculate the final
velocities from there, with the difference we're dealing with scroll
units, and not pixel distances.
https://bugzilla.gnome.org/show_bug.cgi?id=749770
If a GtkScrolledWindow is just unmapped and promptly mapped again, the
indicators are left in a semi-visible state, so the GdkWindow isn't raised
properly above scrolledwindow content. This inconsistent state went away
the next time the indicator is hidden.
So, reset all state about indicator window visibility, animation
progress and conceil timer on ::unmap, this will be enough to make the
indicators start out hidden like on newly created scrolledwindows.
Just use the last coordinates given on XdndPosition/drag_motion() in
order to trigger scrolling.
When running on Xwayland, the pointer position is unknown at this
stage on the X11 side, so the coordinates given here are bogus.
This change avoids both roundtrips and this situation.
https://bugzilla.gnome.org/show_bug.cgi?id=749679
Just use the last coordinates given on XdndPosition/drag_motion() in
order to trigger scrolling.
When running on Xwayland, the pointer position is unknown at this
stage on the X11 side, so the coordinates given here are bogus.
This change avoids both roundtrips and this situation.
https://bugzilla.gnome.org/show_bug.cgi?id=749679
Just use the last coordinates given on XdndPosition/drag_motion() in
order to trigger scrolling.
When running on Xwayland, the pointer position is unknown at this
stage on the X11 side, so the coordinates given here are bogus.
This change avoids both roundtrips and this situation.
https://bugzilla.gnome.org/show_bug.cgi?id=749679
Load themed cursors from the same places they are loaded on freedesktop systems,
but use W32 API functions to do so (works for .cur/.ani cursors instead of X
cursors).
Refactor the code for cursor handling. Prefer loading cursors by name.
Do not load actual cursors when loading the theme. Find the files and remember
the arguments/calls for loading them instead. Keeping HCURSOR instance in the
hashmap would result in multiple GdkCursors using the same HCURSOR. Given that
we use DestroyCursor() to off them, this would cause problems (at the very
least - DestroyCursor() would fail).
Store GdkCursor instances in a cache. Update cached cursors when theme changes.
Recognize "system" theme as a special (and default) case. When it is set,
prefer system cursors and fall back to Adwaita cursors and (as a last resort)
built-in X cursors. Otherwise prefer theme cursors and fall back to system and
X cursors.
Force GTK to use "left_ptr" cursor when no cursor is set. Using NULL makes
it use the system default "arrow", which is not the intended behaviour when
a non-system theme is selected.
Ignore cursor size setting and query the OS for the required cursor size, as
Windows (almost) does not allow setting cursors of arbitrary size.
https://bugzilla.gnome.org/show_bug.cgi?id=749287
Even if a window doesn't support client side shadow
(gtk_window_supports_client_shadow returns FALSE), don't assume the
shadow width is zero, as CSD may have been enabled anyway (meaning
priv->client_decorated is TRUE). In that case we still need to report
the correct width.
https://bugzilla.gnome.org/show_bug.cgi?id=749451
Not everything has a replacement in the API, as the drawing model
changed considerably; nevertheless, this should help out developers
porting from the deprecated GtkStyle API.
If CSD is enabled with shadow even though it "shouldn't"*, the width
should still be calculated correctly. This fixes a regression caused by
b1e5ad469c.
* gtk_window_should_use_csd () returns false
https://bugzilla.gnome.org/show_bug.cgi?id=748615
