Only HighContrast has a clear problem, and this avoids some probably
unwanted changes of certain colours in the weird greyscale emoji I have
available to test here.
On button release, we were popping down if the event widget was anything
but priv->button. This broke scrolling by clicking a mouse button, i.e.
when releasing a click in the trough or finishing a drag of either bar.
That’s unexpected, inconvenient, and pointless. So, let’s stop doing it.
https://bugzilla.gnome.org/show_bug.cgi?id=738893
We were only selecting a section’s button if the adjustment y coord was
within its heading, so scrolling slightly into it unchecked all buttons.
This also fixes how we could end up with the first 2 selected, somehow.
https://bugzilla.gnome.org/show_bug.cgi?id=787172
Nice try, but size groups don't work with invisible widgets anyway.
Invisible widgets request 0×0.
[reapplying after accidental reintroduction in the cloudproviders patch;
see https://bugzilla.gnome.org/show_bug.cgi?id=786123#c39]
Use opacity to differentiate unselected/hovered/selected buttons. It had
assumed bg < border < fg colours, which may be false, as in Adwaita:dark
This also means we do not need to special-case for the backdrop state.
https://bugzilla.gnome.org/show_bug.cgi?id=786956
in a specific case, which was applying .slider as a class on the parent
switch, instead of correctly selecting on its child node named slider.
This makes the border on the outside of a switch in a selected listbox
row look better in the light variant. Since the code was never removed,
it was clearly meant to work, and making it work is a clear improvement.
Using this produced warnings about the Pango syntax of <Family> <size>
being deprecated, and the size being invalid due to no unit specified.
Also, that multi-word font family presumably wouldn’t work as expected.
This reverts commit d09bc2b108.
As an English-speaker, I know nothing about complex grammar, and it’s
been brought to my attention that some languages might differ in the
translation of the same command depending on where it appears.
So, I’d better assume everyone else knows better than me. Apologies!
The emoji chooser gets disposed already, because it is attached
to the toplevel as a popover. Doing it again when the object data
is cleared is leading to a crash.
https://bugzilla.gnome.org/show_bug.cgi?id=787103
