Adapt to the new element names in the previous commit.
This also adds back a selected state which gets used
for when the focus is placed on the separator with F8,
just so this functionality is not forgotten.
This commit creates entry and button subnodes for the buttons
in GtkSpinButton. The nodes are ordered like this for horizontal
spinbutton
+ entry
+ image.left
+ image.right
+ progress
+ button.down
+ button.up
and like this for vertical ones:
spinbutton
+ button.down
+ entry
+ button.up
This arrangement requires cooperation from GtkEntry to place
the entry subnodes correctly, and some small changes in the theme.
This commit also fixes progress rendering in vertical spin buttons.
This changes widget paths for widgets with a CSS name to return that CSS
name, now that we have added API for it.
This means that style properties are now matches using the CSS name.
Also fix the theme to use the correct name when matching style properties.
Use the new element names instead of the type name and style
classes.
Note that there is one problem with moving away from type names
here: it turns out that style properties only work if the selector
uses the type name.
Disclosure triangles are usually used pointing down, however
in this case the popover spawns in the upper direction, which
makes it odd looking.
Instead of pointing always down or up, point down when not toggled and
animate a rotation when toggled.
https://bugzilla.gnome.org/show_bug.cgi?id=756568
we used to consider every button inside osd containers linked,
this is not true anymore, now those buttons behave normally.
This will clearly cause breakage in applications.
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.
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.
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.
The .button:link .label selector matches any label "inside" a
link button. And a label inside the context menu counts as inside
for this purpose. This causes the text-decoration property to
leak into the context menu, even though the property is not
inherited. Avoid this by tightening the selector to
.button:link > .label.
https://bugzilla.gnome.org/show_bug.cgi?id=753451
I was assuming that GtkVolumeButton and GtkScaleButton could only
contain a icon, now they get the image-button padding by default,
but if the text-button class is applied it is not overridden.
We were using GTkTreeView in a simple list. Also, as we know,
GtkCellRenderers are not the best way to theme and manipulate
widgets.
So instead use a GtkListBox to modernize the GtkPlacesSidebar,
and in the way clean up some parts of the code (like headings)
which were not used anymore.
Also we don't use a model anymore, since the data is simple
enough to manage it in a subclass of the row itself.
- use dark theme assets for the checkboxes and radios
- darken the popover for legibility (white bg/black text is
really the most problematic background to have).
unfortunatley in terms of SCSS structure this is further digging us into the
hole of specificity. It would be much nicer to set the .osd class on the popover
and have everything just work. I'm sure we'll end up using OSD styled popovers
outside the touch context.
https://bugzilla.gnome.org/show_bug.cgi?id=750396
- use consistent widget style. unfortunately using assets
- light/dark variant
- new assets for text selestions, using existing slider asset for
insertion point
https://bugzilla.gnome.org/show_bug.cgi?id=750396
Added another :not() to fix the first and last swatches in the
first section of colorpicker.
Dodge the artifacts due to stacked anti-aliased rounded corners by
increasing the radius of the base object by 1px.
