Lots of applications often use GtkFrame as a giant toplevel container,
and that means that they get size allocated often. When frames get size
allocated, they invalidate their entire widget tree, even if they
haven't changed size or anything like that happens at all. This is
because the shadow / label needs to be redrawn if the child changes
size. We can optimize this out and only mark ourselves for a redraw if
the child has actually changed its size.
GtkButtonBox adds the "linked" class to its style context when its
layout is set to GTK_BUTTONBOX_EXPAND. It shouldn't ever make sense to
have spacing between buttons in that case, as themes generally draw
linked elements with a continuous border.
Thus, always set spacing to 0 and ignore GtkDialog's button-spacing
style property when the layout is set to EXPAND.
Also remove the now-redundant css rules which set button-spacing to 0
for message dialogs.
https://bugzilla.gnome.org/show_bug.cgi?id=752131
Change things around so that warp-to-click and jump-by-pages are
bound to left-click and shift-left-click, depending on the value
of gtk-primary-button-warps-slider. Autoscrolling is bound to
right-click.
To achieve this, reorganize gtk_range_multipress_gesture_pressed
so that the functions are clearly separated.
Make shift right-click on the trough start autoscrolling. The
autoscrolling is similar to the way steppers operate now, with
the difference that we vary the scrolling speed based on the
distance of the pointer from the widget.
Clicking on steppers does different things depending on which
button you use. We used to scroll to the end on secondary click
and use high-speed autoscrolling on middle-click. Switch these
two around, since the scroll-to-end functionality is less likely
to be useful, and the seconary button makes the autoscrolling
more easily available.
Even if we only ever hit the code with a singleton selection,
calling gtk_tree_selection_get_selected is not ok if the tree
selection mode allows multi-selection. Replace all calls to
gtk_tree_selection_get_selected in the file chooser code with
callback loops iterating over the selection. This problem
was introduced with the recently added rename and delete
menuitems.
Whenever we change directories, we unset the model, and then
we set a new model. This causes several emissions of
GtkTreeSelection::changed, for each of which we do a bunch
of work to update the path bar, the location entry, etc.
We can savely ignore some of these signals, and do less work.
There is no need to animate things when we are just setting up
the startup mode, so disable transitions in the revealer and
the stack. Pointed out by Carlos Soriano
There was some code that lead to the places sidebar loosing track
of the row being dragged if a motion event came in between letting
go of the button and the drag snap-back animation ending. This would
cause us to not show the row again, giving the appearance that it
was 'lost'.
https://bugzilla.gnome.org/show_bug.cgi?id=751448
If we don't find Xft values in the X resource db, simply fall
back to the values that are hardcoded in /etc/X11/Xresources
anyway. Extra trickery with likely-made-up screen dimensions
is not going to yield better results, and only makes for a
deeper rabbit hole when debugging.
Support was added for GDK_HINT_ASPECT in
gdk_quartz_window_set_geometry_hints though with one restriction:
min_aspect and max_aspect have to be equal, which I believe corresponds
to the most common usage. A warning will be printed if this condition is
not met but min_aspect will be used anyway.
The menu tracker does a better job of this than we can, so move over to
using it instead.
This fixes issues with './testgmenu --import' not properly displaying
the language submenu.
https://bugzilla.gnome.org/show_bug.cgi?id=752016
The current widget lookup code bails out on insensitive widgets, there's
however legit cases where we want DnD handled by a parent of the insensitive
widget, so just keep going upwards in that case.
We also use now the widget state flags, because get_sensitive() doesn't
propagate across hierarchies, so we could conceivably find a drop site
inside an insensitive widget.
https://bugzilla.gnome.org/show_bug.cgi?id=751793
