GitLab

We don't support multiple screens anymore, so there is no need
for marking API as multihead safe any longer.

These should just be replaced by CSS margins, etc.

The non-zero default default-border was causing buttons to shrink as
the focus moves around them. Themes which want a default-border should
define it explicitly.

It turned out not all code was fully prepared to handle multiple buttons,
this avoids respawning https://bugzilla.gnome.org/show_bug.cgi?id=731020.

The code is actually prepared for that, the gesture was initially limited
to only handling GDK_BUTTON_PRIMARY because it only used to handle row
activation.

These variables were last used before moving row activation to being
managed by a gesture.

The multipress gesture on the bin window now also does all the business related
to row selection. As row selection and activation can't be easily decoupled, this
fixes certain problems around ::row-activated being emitted on NULL paths.

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=731455 and
https://bugzilla.gnome.org/show_bug.cgi?id=731018

This gesture acts only on events from the bin window, and checks that
either the pressed row is draggable, or the conditions for rubberband
selection apply.

A multipress gesture takes care of autosizing on double click, and
a drag gesture is used for both column dragging/resizing (only one
can happen at a time).

This happens in an event handler, and the button event should be
expected to have the right coordinates on the event window already.

This makes gtk_gesture_get_current_button() work properly on GtkGesture::end, and signals
spawn from there on subclasses.

We need to show child windows and handle in the right order,
otherwise the input-only handle window ends up under the children
where it is useless.

When placing tooltips, the csd shadow will get 'pushed up' and
may end up underneath the pointer. We don't want this to cause
the tooltip to be hidden, because that leads to flickering, so
ignore the shadow when finding the widget under the pointer.

For csd override-redirect windows, we don't set up resize handles,
but we were not ignoring the margin in all places, causing some
size calculations to go wrong.

GtkText, GtkList and GtkCList don't exist anymore.

It's now just a GtkCssComputedValues + refcount. And
GtkCssComputedValues has its own refcount, so use that one instead.

... from per style data to only existing once per style context. This is
technically an API break because it no longer allows getting different
style properties between save()/restore() pairs, but I don't think this
was ever intended to work that way, as the style property API was to be
used and is used via gtk_widget_get_style().

And it simplifies code a lot.

The file was forgotten in 98954bd1 and
caused test failure. Oops.

It evaluates to "current state" in all cases, so no need to special case
it.

I can't find anything that uses this struct and it seems to be replaced by GdkDeviceGrabInfo

This will be used to make the popup appear in the inspector.

As requested by the Adwaita guys.

Introduced in 2d88a3ae

Without this, we don't get object hierarchy, among other things.

These were missing.

We used to accept the same syntax for text-shadow and icon-shadow as
we accept for box-shadow. However, box-shadow does accept a spread and
the inset keyword while the others should not.

The signal needs to be emitted after the text insertion as at-spi gets
the text to compute the inserted text due to the AtkText::insert-text
signal not containing it.
Also adjust position to reflect changes to the offsets.

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

Not attempt to make this look good, just to demonstrate
that themes can in fact do it.

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

Use the new private GtkWindow api to request
client-side decorations for tooltips.

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

When placing tooltips, we don't want the shadow to influence
our choice.

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

This is old code from dating back many years. Nowadays, we can
just use css drawing and csd windows to achieve much the same
effect.

Themes will need some adjustment for this change.

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