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
GtkButtonBox adds the "linked" class to its style context when its
layout is set to GTK_BUTTONBOX_EXPAND. It shouldn't ever make sense to
have spacing between buttons in that case, as themes generally draw
linked elements with a continuous border.
Thus, always set spacing to 0 and ignore GtkDialog's button-spacing
style property when the layout is set to EXPAND.
Also remove the now-redundant css rules which set button-spacing to 0
for message dialogs.
https://bugzilla.gnome.org/show_bug.cgi?id=752131
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.
It turned out that using mwm hints to instruct wms to
create border-only decorations is not really working
universally. So, instead of doing this, render a solid
frame without shadow on the client-side to handle this
case.
https://bugzilla.gnome.org/show_bug.cgi?id=746222
Signed-off-by: Olivier Fourdan <fourdan@xfce.org>
Since widgets subelements are now both widget childs and widget
classes, say .spinbutton.button and .spinbutton .button, the linking
logic needs to be adapted to be stricter with child selectors.
This fixes vertically linked spinbuttons.
This subdirectory gets in the way when integrating the inspector
build more fully with GTK+, and does not really add anything.
Just move everything one level up.
