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
Synchronizing the visible child with the switcher's toggle buttons can
lead to GtkButton::clicked being emitted twice. Once for the button
that was active before, and once for the button that we just activated.
This leads to notify::visible-child being called twice and one of
them is with the wrong child.
Let's deal with this in the same way we handle the visible child
changing underneath us.
https://bugzilla.gnome.org/show_bug.cgi?id=749021
The window state 'client_decorated' will only be set the window is being
realized. If anyone tries to get the shadow size before that it'd get
the with as if there always was no shadow.
This avoids negative sized opaque regions caused by the allocation being
smaller than shadow.
https://bugzilla.gnome.org/show_bug.cgi?id=748615
If we have a GObject property that is also a GObject, we should be able
to view additional information on that object (even if the param spec
is read-only).
We were relying on indirectly getting notify when fontconfig
configuration changes, by GtkSettings translating the timestamp
change into a style-invalidation, which gets fed through the
css invalidation machinery. That machinery has gotten good enough
at optimizing away redundant changes that it no longer emits
::style-updated in this case.
So, instead make the font chooser listen directly to what it
cares about: the fontconfig change notification from GtkSettings.
We can use the GtkSettings:gtk-fontconfig-timestamp property to decide
whether or not we should reload fonts on style and screen changes. This
should avoid doing a lot of work with large font collections when only
the theme has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=748782
Add a new API, gtk_popover_set_default_widget, that can be
used to make a widget act as default while the popover is
shown. This is useful in dialog-like popovers.
http://bugzilla.gnome.org/show_bug.cgi?id=747664
Making a container focusable is rarely the right thing to do.
It typically breaks the focus chain, and makes the container
contents unfocusable, as was the case here.
We have a number of cases where properties should have their
default value overridden in a subclass, but haven't because thats
annoying to do. We also have properties where the absence of
an explicit value has context-dependent meaning.
Add a list of exceptions for these cases.
The previous commit removed default-valued properties,
but apparently that has a negative effect for grid
packing properties, so put the explicit value back.
