Now that scripts are loaded as external modules, there's no reason
anymore for bundling them with the gnome-shell executable. Just
move the scripts into a dedicated folder in tests/ and run them
from there.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2812>
The purpose of the tool has shifted from running a limited set
of performance tests repeatedly to collect performance data
and catch regressions, to a wrapper that drives gnome-shell via
scripts for tests.
With that, the concept of a "default" script doesn't really make
sense anymore.
Instead, turn the argument from an optional flag into a required
parameter. This will allow us to stop bundling the existing tests
in a follow-up commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2812>
The original purpose of the tool was to collect performance data
that would optionally be uploaded to a server in Owen's living
room. While the corresponding scripts are still included (although
the server was probably dismantled years ago), the tool is mainly
used for running gnome-shell with scripted tests nowadays.
Rename the tool to reflect that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2812>
Environment variables aren't the best option to pass parameters
to a process (wouldn't it be "fun" if SHELL_PERF_MODULE appeared
in a regular user session?).
Instead, use a (hidden) --automation-script command line flag to
specify a script file that should be used to drive an automated
session.
As a side effect, the script no longer has to be relative to the
main module itself, so it will be possible to run scripts that
aren't bundled with the shell sources.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2812>
Add common test environment variables to a default test setup so that they
don't need to be repeated everywhere.
Also ensures that we're always using the gsettings memory backend to never
interfere with local environment.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2661>
This test runs all of GNOME Shell using the headless backend inside a
mocked D-Bus environment. The basic test tests, well, basic things, like
the panel menu, the overview, showing the app grid view, as well as
going back to the session view.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
The module exports a `addObjectSignalMethods()` method that extends
the provided prototype with `connectObject()` and `disconnectObject()`
methods.
In its simplest form, `connectObject()` looks like the regular
`connect()` method, except for an additional parameter:
```js
this._button.connectObject('clicked',
() => this._onButtonClicked(), this);
```
The additional object can be used to disconnect all handlers on the
instance that were connected with that object, similar to
`g_signal_handlers_disconnect_by_data()` (which cannot be used
from introspection).
For objects that are subclasses of Clutter.Actor, that will happen
automatically when the actor is destroyed, similar to
`g_signal_connect_object()`.
Finally, `connectObject()` allows to conveniently connect multiple
signals at once, similar to `g_object_connect()`:
```js
this._toggleButton.connect(
'clicked', () => this._onClicked(),
'notify::checked', () => this._onChecked(), this);
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1953>
Replace deprecated functions with their direct replacements:
- dep.get_pkgconfig_variable() → dep.get_variable()
- prg.path() → prg.full_path()
- source/build_root() → project_source/build_root()
In one case we need meson.global_source_root() that was only
added in meson 0.58, so bump the requirement to that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2077>
Meson is on track to replace autotools as the build system of choice,
so support it in addition to autotools. If all goes well, we'll
eventually be able to drop the latter ...
https://bugzilla.gnome.org/show_bug.cgi?id=783229
