Instead, rely on people passing fallbacks explicitly.
Alternatively, GThemedIcon provides the functionality to create
fallbacks, which is what GtkImage and the testsuite now use.
That method is slightly better, too, so the expected test results
have been updated accordingly.
There is no way to query contexts or do anything useful with them.
So don't keep track of them and don't make them an argument in public
APIs with the docs saying "I don't know what to use here, maybe read
some spec somewhere".
We expose no API to get at any colors for drawing symbolics, so we
shouldn't have APIs to draw with them.
Apart from that, those APIs look like a box of crayons, not like an
icontheme.
Most users were just forgetting to set the proper flags.
And flags aren't the right way to set this anyway, it was just
acceptable as a workaround during GTK3 to not break API.
The API encouraged wrong usage - most of the users were indeed wrong.
Use the correct version instead:
gtk_icon_theme_get_for_display (gtk_widget_get_display ())
Instead of just doing radical change matching on the node itself, also
consider the parent nodes via the bloom filter.
This means a radical change is now also one where the parent
name/id/classes change, but since that's considered a radical change on
the parent already, those things are slow anyway.
Improves the benchmark times for CSS validation during backdrop
transitions in widget-factory from 45ms to 35ms on my machine.
:not() selectors cannot be radical because the bloomfilter only knows if
a value is set in any of the nodes, but cannot determine the opposite
(if a value is not set in at least one node), but that would be required
for:not() selectors.
However, this is very unlikely to happen in the real world, so it's not
worth optimizing.
Unfortunately, change tracking could know this, so by excluding the
:not() selectors from radical changes, the change tracking will now pick
them up. If that turns out to be a performance problem, we need to add a
special category for radical not filters, so change tracking and bloom
filters can deal with them.
The testcase demonstrating the problem in widget-factory has been
extrated and added.
Properly handle diff(1) failing.
In this particular case, the test passed a NULL input file to the diff
(that was fixed, too) and then diff only found one input file and
aborted.
But without this fix, we'd also not catch other abortion reasons for
diff() - as long as it exited in any way, we were happy.
Some of these test cases involve :not, and thus are affected
by our now correct handling of it for change computation.
All of them are affected by the window now being visible.
Add various tests for the change flag computation that
we do in the css selector tree.
test1: Just test the basic machinery of this test
test2: Trigger every change flag at least once
test3: Test that multiple states combine as expected
test4: Test negations (known to produce wrong results)
test5: Test a complex selector (not producing the expected
output atm)
widget-factory.ui:
The real thing: widget-factory+Adwaita. Note that
this expedts to be run with GSETTINGS_BACKEND=memory
Note that test4 checks the wrong results that we currently
produce for selectors involving :not. It will have to be
updated when we fix the handling of :not. The widget-factory.ui
testcase will certainly also be affected.
