This commit makes sure we can properly run the tests in a headless
environment, i.e. they don't mess with the user's X display or their
session bus. The latter is also needed for parallel tests as they fail
to simultaneously own the same name on the session bus.
Replaced the "xvfb-run" meson option with the "headless" option, which
is more intuitive (and also more correct, since we now also require
`dbus-run-session` to run the tests, not only `xvfb-run`).
Finally, note that we need a version of `xvfb-run` that supports the
`-d` (`--auto-display`) option. The problem with `--auto-servernum`
which is also regularly used, is that it doesn't shut down cleanly,
returning a non-zero exit code, wich makes the test fail.
Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/5078
For now the whole pygimp folder is considered deprecated and will
probably end up removed (though there are some discussions and a merge
request to possibly revive it, we'll see!).
From commit 529aa743:
> `g_object_notify()` actually takes a global lock to look up the
> property by its name, which means there is a performance hit (albeit
> tiny) every time this function is called. For this reason, always try
> to use `g_object_notify_by_pspec()` instead.
While just _loading_ GIMP on my machine (ie during the splash screen)
`g_object_notify (curve, );` got called more than 6000 times already, so
it's not an unused path.
Note that it's also less easy to make an accidental typo when using
`g_object_notify_by_pspec()`, as the compiler will complain about the
enum value being incorrect.
There is no non-hackish way of fixing this without adding a new
"use-opacity-paint-mode" property to GimpToolPreset and a new toggle
in GimpToolPresetEditor. Restoring opacity and paint mode can now be
controlled explicitly, and defaults to TRUE.
`GET_PRIVATE()` expands to `gimp_viewable_get_instance_private()`, which
just returns an offset of the passed on pointer. As such, it's safe to
call this on any value (even NULL) and to put it at the top of the
function block, saving some lines.
From commit 529aa743:
> `g_object_notify()` actually takes a global lock to look up the
> property by its name, which means there is a performance hit (albeit
> tiny) every time this function is called. For this reason, always try
> to use `g_object_notify_by_pspec()` instead.
While just _loading_ GIMP on my machine (ie during the splash screen)
`g_object_notify (viewable, "icon-name");` got called more than 4000
times already, so it's not an unused path.
Note that it's also less easy to make an accidental typo when using
`g_object_notify_by_pspec()`, as the compiler will complain about the
enum value being incorrect.
Meson has a very useful tool for combining a set of linked libraries and
compiler arguments (like an internal pkg-config):
`declare_dependency()`. Use this command to ensure that we can easily
reuse libapp* over multiple libraries, executables and tests.
That way, if we also add a new dependency later on in one of the libapp
libraries, this won't need to be added multiple times.
The tests weren't building because they weren't linked to the static
libraries.
Note that some tests still need fixing, but at least they can be
built/run now.
This gives a big cleanup in the meson.build files of the plug-ins.
It's also quite a bit more maintainable, since anything that changes in
libgimp's dependencies, linkage, ... doesn't have to be copy-pasted into
each plug-in.
By using Meson's `declare_dependency()`, we can avoid specifying the
linked libraries, dependencies and includes we need over and over again.
Basically, this conceptually acts like an internal pkg-config.
`gimp_unit_store_get_value()` clashes with the `get_value()` method of
its parent class GtkTreeStore. This means trouble for bindings, as seen
here in some pseudocode:
```vala
var unit_store = new Gimp.UnitStore();
// Which function are we referencing here, the one from GtkTreeStore or
// the one from GimpUnitStore? Worse, they both have different arguments
unit_store.get_value( ... )
```
Especially need to watch out with forgetting `(array)` and `(out)`
annotations, as they can really give a different API in certain (if not
most) bindings.
GtkHBox is a deprecated version of GtkBox, which we don't even use
anymore. It confuses the gtk-doc a build though, so let's fix it to get
rid of another warning.
When using GIR-based bindings that will eventually include the header
files (like Vala), we need to make sure to tell the gir-scanner what
file that is. Otherwise tools like `vapigen` have to make an educated
guess (which will be wrong).
