GtkAssistant is bending the rules about child properties
of non-direct children, and the recent fix to accomodate
GtkInfoBar changes broke things. The effect was that child
properties of assistant pages in ui files were just not
applied, so all pages ended up without titles and with
the normal page type, leading to broken assistants all
over the place.
https://bugzilla.gnome.org/show_bug.cgi?id=706756
GtkAssistant supports not showing the sidebar with the page
titles (if the page have no titles). Unfortunately, we were
hiding the sidebar in this case, but still rendering the frame
behind it, leading to a broken appearance.
Horizontal scrolling is unusual, but specifying some extra offscreen
space for it in free in the normal case where the viewport is the
same width as the canvas anyway, so lets do it.
If the new requested surface size is enough larger than the previous
one (but the old is still larger than the absolute minimum),
reallocate it anyway.
This fixes an issue where the text view initially requested a really
small extra size which was then increased but that didn't "take".
This patch uses GtkPixelCache to render the contents of the widget,
and typically a bit more, to an offscreen surface. The pixel cache in
turn manages rendering to the actual surface for the widget.
The current strategy for the size to render is the size of the widget
plus half the height.
https://bugzilla.gnome.org/show_bug.cgi?id=701125
There were some code added to this file that is meant for the X11 backend,
but they are being unconditionally built. Add build-time checks for the
X11 backend for these to fix the build on non-X11 platforms.
Due to the work on gdk_cursor_new_from_surface (commit b2113b73),
get_cursor_for_pixbuf() in GdkDisplayClass was converted to
get_cursor_for_surface(), which means the GDK Win32 backend needs to be
updated for the code to build and run on Windows, plus some function
prototypes and declarations/calls need to be updated as well.
https://bugzilla.gnome.org/show_bug.cgi?id=705980
We'll use a style class to be able to give this a different appearance,
but for the time being we don't really need to give this such different
margin.
https://bugzilla.gnome.org/show_bug.cgi?id=706592
When setting the lines property, the label will be ellipsized
to that many lines, with the ellipsis only appearing in the
last line. This is different from how ellipsization of multi-line
labels normally works in GTK+.
"title_box" is used for both a custom header bar and for a titlebar.
Since we want to help differentiate these cases in the code, rename
everything titlebar-internal to use "titlebar_".
https://bugzilla.gnome.org/show_bug.cgi?id=706529
This used to point to the GtkPathBar, which doesn't accept mnemonic activation, anyway.
This whole thing was a leftover from when we had a combo box to select a folder, but
this is no longer the case.
https://bugzilla.gnome.org/show_bug.cgi?id=706448
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This way, the Wayland and the regular clipboard implementation can both
be compiled in and selected based on the display in use.
One thing potentially broken now is text mime type handling as Wayland
seemed to use different mime types in some places.
The state of the widget is not enough now to cache the pixbuf - we also
have to take into consideration the image effect itself, since the state
on the actual GtkStyleContext we use might not change, e.g. because the
change was on a parent context.
https://bugzilla.gnome.org/show_bug.cgi?id=705443
We should set the appropriate style classes when we have
constructed the content and know if it is a label, an image,
or both. Doing this in the convenience constructors is
problematic for language bindings, and misses out when the
content is changed after construction.
