This is rarely what you want, so lets turn it off
by default.
Update the one place in our demos where we want to
draw a value, add support for this to gtk-builder-tool,
add a test and mention this change in the migration
guide.
The parser got its chars mixed up while parsing numbers
like 2.3e-04. While it is unlikely to meet such numbers
in human-generated css, we do have them e.g. when saving
render node trees with transforms.
Also add some css parser tests for number parsing.
A radiobutton without indicator is really just a togglebutton with a
group.
A radiobutton with indicator is really just a checkbutton with a group.
Make checkbutton its own widget not inheriting from GtkButton.
GtkRadioButton could be removed but it stays for now.
Radiobutton && !draw-indicator => Togglebutton
Checkbutton && !draw-indicator => Togglebutton
Radiobutton && draw-indicator => CheckButton + group
To build a better world sometimes means having to tear the old one down.
-- Alexander Pierce, "Captain America: The Winter Soldier"
ATK served us well for nearly 20 years, but the world has changed, and
GTK has changed with it. Now ATK is mostly a hindrance towards improving
the accessibility stack:
- it maps to a very specific implementation, AT-SPI, which is Linux and
Unix specific
- it requires implementing the same functionality in three different
layers of the stack: AT-SPI, ATK, and GTK
- only GTK uses it; every other Linux and Unix toolkit and application
talks to AT-SPI directly, including assistive technologies
Sadly, we cannot incrementally port GTK to a new accessibility stack;
since ATK insulates us entirely from the underlying implementation, we
cannot replace it piecemeal. Instead, we're going to remove everything
and then incrementally build on a clean slate:
- add an "accessible" interface, implemented by GTK objects directly,
which describe the accessible role and state changes for every UI
element
- add an "assistive technology context" to proxy a native accessibility
API, and assign it to every widget
- implement the AT context depending on the platform
For more information, see: https://gitlab.gnome.org/GNOME/gtk/-/issues/2833
We are using floats for rgb, and we don't need more precision
for hsl colors either. We use hsl for computing color expressions
like shade(), lighter() and darker(), which are not precisely
specified anyway.
This commit updates the one test where the output changes a
tiny bit due to this.
Always keep the order:
- [value]
- [marks.top]
- [marks.bottom]
- trough
Which makes sense given the rendering order. Slider should be drawn
after the marks.
Makes it possible to simply remove the custom snapshot implementations
in scale and range. And Adwaita does not depend on the node order
anyway.
This was testing something that shouldn't be possible
anyway: Adding more than one child to a bin. With the
bin removal, this now just overrides the child so
only one child is left in the end.
Just remove the test.
For some reason, these tests are flaky in ci,
they always work locally for me. So, until
we use the data these tests produce for something,
lets just turn them off.
This makes meson actually parse the individual test
results. Most of the time, it does not make a difference,
but one case where it does is when all the individual
tests of a binary are skipped, meson will mark the
test as skipped.
These are always set to the same value as the corresponding border
radius properties. They are also non-standard, so remove them and
replace them with the border radius properties everywhere.
Fixes#2414
It it hard to control which of the csd style classes we get,
since it depends on details of the X server or compositor.
Explicitly ignore this difference by replacing .solid-csd
with .csd in the output.
Stylecontexts are on their way out and I'm removing API that the
testsuite was relying on, so remove the tests.
Put the useful parts of the tests elsewhere.
This adds a GDK_DEBUG=default-settings flag which disables reads
from xsettings and Xft resources, and enables this for the testsuite.
This is one less way to get different testresults depending on the
environment. In particular, it was failing the css tests for me
due to getting the wrong font size because i have a different dpi.
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.
The bug was introduced in commit:
9b7640b8 by Benjamin Otte, 2012-03-26 17:24:02
styleproperty: Make _gtk_style_property_parse_value() return a CssValue
In that commit, `values` changed from `GValue*` to `GtkCssValue**`,
but one `!G_IS_VALUE (&values[8])` was left untouched. As a result,
if `border` shorthand contains anything after color, it might crash,
depending on memory layout.
New test included.
Fixes: #751
The expander icon is renamed from "arrow" to "expander".
The expander widget itself is renamed from "expander" to
"expander-widget" (Better ideas welcome).
This makes it possible to have an "expander" icon in more places then
the GtkExpander widget (in particular in tree lists) and not
confuse it with arrows.
Instead of just checking that the line of the error message is correct,
assert that start and end position are on the correct character offset.
Also fix all the tests to conform to this.
Make the test use an actual integer property that accepts negative
numbers (opacity) instead of one that wants units (margin-top) or
can't deal with negative numbers (everything else).
This library is meant to be the new CSS library that gets used from GDK,
GSK and GTK for string printing and parsing.
As a first step, move GtkCssProviderError into it.
While doing so, split it into GtkCssParserError (for critical problems)
and GtkCssParserWarning (for non-critical problems).
The `buttons` test for CSS nodes sets the second RadioButton as the
active one, whereas the first RadioButton is not set as active.
Nevertheless, the reference output says that the first radio button
should match the `:checked` selector, whereas the second radio button
should not.
The fact that the test currently passes is a mystery.
