We used to get an implicit -lm from gdk-pixbuf, but that has
recently been changed to not inject extraneous libraries into
link lines, so we have to do it ourselves now. This is more
correct, anyway.
These functions are implementations of the AtkText api on top
of a PangoLayout, and are intended to replace GailTextUtil.
Since gtkpango.h is a private header, also remove the individual
inclusion prohibition.
The tool works like this:
./accessibility-dump [FILE ...]
If no files are given, all files with the extension ".ui" in the current
directory are taken. For every file "test.ui", the following steps are
performed:
1) test.ui is loaded using GtkBuilder
2) The accessible for the window is loaded
3) The information of accessible is converted into a string using a
syntax defined in this test file
4) The generated string is diffed with the file "test.txt"
5) If the diff is empty, the test is a success, if not, the test fails.
6) The diff is output when the test runner is run with --verbose
So to add a test named "test", create a file called "test.ui", put it
into this directory. Then create the expected output file "test.txt",
put it into this directory too. You can create the initial version of
this file by invoking "./accessibility-dump --verbose test.ui". The
output will contain the expected text and can be copy/pasted into the
text file.
This functionality adds a new 'Printer Profile' entry to the 'Color' page in the
UNIX print dialog if colord support is enabled.
This shows the user what color profile will be used for the settings they have
selected, and if no profile or the default profile is going to be used.
We are deliberately not allowing the user to _change_ the selected profile, as
the ICC profile is an implementation detail, and we should not change the other
print settings based on the characterization state.
The OpenICC group broadly recommend showing the profile that is used, so that
power users can be sure the correct profile is being used at the right time.
Normal users won't care, as they don't know how horrible the color match is
without profiling the printer and media.
Tests in the parser need 1 or 2 files:
1) test.css
2) test.ref.css (optional, defaults to test.css)
The test instantiates a CSS provider, loads test.css, then dumps the
loaded file to test.out.css and then checks that that file matches
test.ref.css. If not, it dumps a diff between those two to the log and
fails.
You want to run the test with --verbose to get the output dumped to
stdout.
Add a new test runner supposed to do a lot of generic tests. Run it like
this:
./gtk-reftest [OPTIONS] TESTFILE [TESTFILES...]
where FILE is a GtkBuilder ui file to run.
For a general test named "test", you want to have the following files:
1) test.ui
2) test.ref.ui
3) test.css (optional)
The test will then check that test.ui and test.ref.ui are rendered
identically with the provided css.
In detail, for every provided TESTFILE the test runner will:
1) Add the css to the default screen
2) Load the test.ui file and the test.ref.ui file
3) Grab the first GtkWindow subclass widget
4) gtk_widget_show() it and take a snapshot image of its contents into
a cairo surface.
5) Compare the two images to be bitwise identical. If they are not, a
diff image will be created hilighting the differences.
6) Save the images as png files to the output directory named:
- test.out.png (rendering of test.ui)
- test.ref.png (rendering of test.ref.ui)
- test.diff.png (optional, differences from step 5)
7) Fail the test if the two images are not bitwise identical
Credit for the idea of reftests goes to Mozilla and in particular David
Baron. For a larger introduction of why reftests are useful, see
http://weblogs.mozillazine.org/roc/archives/2008/12/reftests.html