GitLab

We've by now disabled and then remved all of the tests that use these
functions because they never worked properly. So let's depecate these
functions before somebody starts using them.

These tests have either been commented out for way too long or use APIs
that we don't want to support.

It looks like the param spec for interpolate-size was
copied from the line above it, which is a read only property.

There is a setter for interpolate-size, and it is implemented in
set_property().

This fixes the ability to sublcass GtkHeaderBar from a UI template which
contains a custom <child type="title"> element.

https://bugzilla.gnome.org/show_bug.cgi?id=757544

When setting the parent of a widget, queue_resize() on the widget will
be optimized away if the widget already had a resize queued.

Plus, we do not need to resize the widget as its size request is not
going to change.

This makes sure that hidden widgets always have priv->alloc_needed set
on them.

The constructor sets that flag, so we want to have it back when we
revert to this state.

This fixes GtkWindow skipping a size_allocate() when reshowing a
previously hidden window and thereby not updating its allocation and
clip. And that in turn would lead to draws not happening and us beig
left with a black window.

There was still style context saving in the draw function,
and the CSS node was not always properly updated and positioned.
Fix these things, and use the same CSS node for the arrow
drawing as well.

It is deprecated now.

Florian Müllner authored Oct 23, 2015 and Matthias Clasen committed Nov 03, 2015

Similar to buttons-in-toolbars, it can make sense for listbox rows
to not take away the focus from the main application view, for
instance when used for navigation. Support this by taking the newly
added GtkWidget:focus-on-click property into account.

https://bugzilla.gnome.org/show_bug.cgi?id=757269

Florian Müllner authored Oct 23, 2015 and Matthias Clasen committed Nov 03, 2015

https://bugzilla.gnome.org/show_bug.cgi?id=757269

Florian Müllner authored Oct 23, 2015 and Matthias Clasen committed Nov 03, 2015

The differences between the existing properties and the newly added
GtkWidget:focus-on-click property are minimal (different owner_type
in GParamSpec), so it is extremely unlikely that dropping the former
would break anything.

https://bugzilla.gnome.org/show_bug.cgi?id=757269

Florian Müllner authored Oct 23, 2015 and Matthias Clasen committed Nov 03, 2015

There are currently three widget that implement such a property, and
there are other widgets for which the behavior can make sense. It
seems like a good time to add the property to GtkWidget itself so
subclasses can choose to respect it without adding their own property.

https://bugzilla.gnome.org/show_bug.cgi?id=757269

Those are not references to other objects, and the device will be mostly
useless if those can't be set again anyway.

https://bugzilla.gnome.org/show_bug.cgi?id=756625

Carlos Garnacho authored Oct 22, 2015 and Matthias Clasen committed Nov 03, 2015

https://bugzilla.gnome.org/show_bug.cgi?id=756670

Carlos Garnacho authored Oct 22, 2015 and Matthias Clasen committed Nov 03, 2015

This way latest shown popovers are ensured to be on top.

https://bugzilla.gnome.org/show_bug.cgi?id=756670

Carlos Garnacho authored Oct 22, 2015 and Matthias Clasen committed Nov 03, 2015

The list of popovers will specify the stacking order, a
_gtk_window_raise_popover() private call has been added so popover
widgets can request being on top.

Also, the stacking on popovers is ensured on gtk_window_size_allocate(),
after the size/stacking changes on the child widget have finished, this
will ensure popovers are kept on top of window contents.

https://bugzilla.gnome.org/show_bug.cgi?id=756670

Carlos Garnacho authored Oct 30, 2015 and Matthias Clasen committed Nov 03, 2015

Those won't have ABS_MT_* axes, so won't be reported has having
XITouchClassInfo. Fallback on these to checking whether abs x/y axes are
available. After the Wacom checks, any remaining device with absolute axes
should be touchscreens, and GDK_SOURCE_MOUSE does indeed just make sense on
devices with relative axes.

https://bugzilla.gnome.org/show_bug.cgi?id=757358

Dhiru Kholia authored Oct 27, 2015 and Matthias Clasen committed Nov 03, 2015

This fix is inspired by,

https://git.gnome.org/browse/glib/tree/m4macros/glib-2.0.m4

https://bugzilla.gnome.org/show_bug.cgi?id=757221

Previous commit 305b34aa "GtkWindow: fix move/get position with CSD"
introduced a regression because some windows presumably use shadows but
actually don't, resulting in a negative offset being wrongly applied.

Problem is that get_shadow_width() would return non-zero shadows even
for windows that have no shadow, thus causing the negative offset.

Fix the logic in get_shadow_width() and gtk_window_should_use_csd() so
that get_shadow_width() returns accurate values.

Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618

Adapt to the changes in the previous commit.

Adapt to the changes in the previous commit.

Use the element name menuitem for GtkMenuItem, GtkCheckMenuItem
and GtkRadioMenuItem. GtkSeparatorMenuItem gets the name separator.
Add a subnode with name arrow if a submenu is attached.
Give the radio and check menu items a subnode with name check or
radio.

We were not actually adding the style classes that the
documentation is talking about, for the !draw-indicator case.
Fix that.

Nobody is reading or writing this field, so we can do without it.

Keep the bottom arrow node at the end, where it belongs.