GitLab

Since being 'activatable' istead of 'button' now that reset
is not needed anymore, the patch is pretty noisy since sass
interpreter changes, those look innocuous though.

Skip tests that don't work under Wayland, such as tests for GtkPlug
and GtkSocket.

Give a clear warning when either of these are realized on a non-X11
screen.

This test really only works under X, since it relies on modifying
the DISPLAY env var.

The check here was obviously meant to filter out cancellations,
not warn for them.

A * selector applies to all widgets, so even GtkBox or GtkGrid - and
most importantly GtkListBoxRow - need to recompute their style because
of the * selector.

By using a more specific one, these common cases aren't affected
anymore.

Fixes slowdowns in gtk3-demo's listbox demo and in gnome-software.

That way, the GTK engine doesn't think that the general .button CSS
might potentially apply to it.
And because combobox button is overly complex and stupid, it cannot be
cached.

So buttons thought they cannot ever cache anything because they might
suddenly end up inside a combobox without noticing and then they'd need
to round their corners differently. Of course they're just regular
"Remove" buttons like all the other 100s of "Remove" buttons in
gnome-software. But hey, better not cache anything for them and
recompute their CSS every time the :hover state changes on one of the
rows.

Nobody is able to look up those hex values.

Get rid of unused values (POSITION_ENUM) and use different values for
NAME and ID.

We can actually share :first-child/:last-child related things now,
because we special case them. So the only positions we cannot cache are
nth-child/nth-last-child.

This should take care of a lot of Adwaita's styling.

Make flat buttons in list-rows work.

Just to show how its done. This will need some tweaks.

We were not taking into account that gtk_flow_box_get_next_focusable
can return NULL, in all callers. Fix that.

This example populates a flow box with buttons, and makes the
flow box children unfocusable, with the intention that the focus
moves directly between the buttons. Currently, keynav does not
work at all in this case.

As pointed out in bug 754143, this reveals a crash in the Wayland
backend.

P_() is meant only for property nicks and blurbs. Everything
else should use _().

Follow-up to 2d83dd62

http://bugzilla.gnome.org/show_bug.cgi?id=754086

This way, we can live without row references.

A side effect is that opening the inspector on the gtk-demo list box
example now only takes 0.5s instead of the previous 3 minutes.

Tree row references are slow to update. And we update the widget list
quite a bit, so when it grows it can get REALLY slow.

Instead of having lots of if statements, create a vtable. This will be
useful for the following patches.

Instead of queueing a new idle handler every time we call
gtk_window_update_debugging(), only queue one if none is queued that.

Saves a lot of work, in particular when templates create context menus
for every row in a large listbox as in the gtk-demo listbox example.

Do not use .button anymore.

This is for 2 reasons:
1. The styling is seperate in our themes, so it doesn't make sense to
   share the style class.
2. Due to the shared styling of .buton, listbox rows inherit all the
   special case styles that exist for buttons - such as linked buttons,
   header buttons, entry buttons, spinbutton buttons, etc. This means
   that the code has to check all these special cases all the time and
   for listbox rows, this is very slow.

P_() is meant only for property nicks and blurbs. Everything
else should use _().

http://bugzilla.gnome.org/show_bug.cgi?id=754086

Explain in the docs that using a model is incompatible with
using filter or sort functions.

GtkFlowBox sort and filter functionality does not work with
models. Issue a warning in this case.

Explain in the docs that using a model is incompatible with
using filter or sort functions.

http://bugzilla.gnome.org/show_bug.cgi?id=752615

GtkListBox sort and filter functionality does not work with
models. Issue a warning in this case.

http://bugzilla.gnome.org/show_bug.cgi?id=752615