The overlap was caused by using pack-end for the arrow, which causes it to be allocated from the other end. Avoid the problem by using pack-start for both the title and the arrow, and reordering them according to xalign.
And document the oddities around it, as requested by Lapo
This same call happens a few lines above.
Hide the sort indicator when it would overlap the column title.
Labels now call gtk_widget_set_clip() so there is no longer a need to exclude them from clipping.
This just moves the function, no actual code changes.
... for newly deprecated gtk_icon_info_get_builtin_pixbuf()
... so that it works with wide separators. Or rather: with separators that don't request 1px size but any other number. Do that by making the placeholder request the same size by indeed stuffing (hidden) separators in it.
Instead "Return value:" or "Return:"
Some of the features we expose can be hardcoded via environment variables. In that case, don't confuse the user by letting them change settings that have no effect.
This makes it easy to test test touchscreen features with a plain old mouse.
This has the same effect as the GTK_TEST_TOUCHSCREEN environment variable, but can be toggled at runtime.
More treeview testing.
The new treeview on page 3 sports expanders, grid and tree lines, alternating row colors, etc.
As requested here: https://bugzilla.gnome.org/show_bug.cgi?id=659926#c2
The displacement animation has been replaced by edge gradients, that have a stronger color the harder overshooting is hit. This makes it possible to remove the internal overshoot window, which was merely used to have contents displaced when overshooting to top/left. Overshooting to bottom/right used to cause queue_resize() to be called on the scrolled window, this isn't necessary anymore either. https://bugzilla.gnome.org/show_bug.cgi?id=731297
This class is meant to render the hint on scrolledwindow corners when scrolling past-limits. https://bugzilla.gnome.org/show_bug.cgi?id=731297
There was this hack, taken verbatim from GtkCList according to the comment, that would recursively translate the allocation during scrolling, and set it on children widgets through the direct gtk_widget_set_allocation() setter. Since commit 4f89eb0, this has caused the wrong clipping areas to children widgets of a textview. The reasons for this seem lost in time, and the approach seems indeed wrong for windowed widgets as the repositioning of those windows couldn't happen. So replace all of this with just a gtk_widget_size_allocate() call, which does work ok for the children widgets embedded in the "multiple views" gtk demo, and ought to work for every other widget. https://bugzilla.gnome.org/show_bug.cgi?id=732900
The reparenting happening on the column header so it gets a movable window breaks the implicit grab, so this is one situation were we want a pointer grab, if just to replace it. https://bugzilla.gnome.org/show_bug.cgi?id=732933
Code was expecting view coordinates, not widget ones, as we're only dealing with horizontal displacements, just adding the horizontal adjustment value suffices. https://bugzilla.gnome.org/show_bug.cgi?id=732933
This ensures that we have a polished out-of-the-box appearance on all platforms.
We're using this name in two places, so match what we are doing for the default theme name, and use a macro.
We use DEFAULT_THEME_NAME in gtksettings.c as well, and this can be a confusing when grepping, so rename this to FALLBACK_ICON_THEME.
This saves some code and lets us reuse the color swatch styling. Among other things, this fixes a lack of discernible border when the selected color is very similar to the background. https://bugzilla.gnome.org/show_bug.cgi?id=680885
This will let us use a suitably sized color swatch in the color button.