Provide all licenses used in the project in a LICENSES folder and
add SPDX license and copyright information for all files in
accordance with the Reuse Software[0] specification.
The copyright information is based on the file's git history,
using a fairly generous definition of "non-trivial".
As of the spec recommendation, the information is generally added
as comments in the files themselves, except for
- NEWS, README and similar top-level standard files, so that
a SPDX code isn't the first thing people encounter
- files that don't support comments (json) or where they'd
be a bit awkward (.desktop, .service)
- anything under po/, to not interfere with translation teams
Those are covered by a .reuse/dep5 files, except for image assets,
where separate .license files are used (It would be possible to
add comments to SVG files, but I don't trust image editors to
preserve them).
[0] https://reuse.software/
Part-of:
<https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/224>
Once the shell is ported to ESM, it will no longer be possible
to replace entire classes (even when exported). Prepare for that
by overriding methods of the regular classes, instead of creating
custom subclasses.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/268>
The eslint job report its results as artifacts in junit format,
so that gitlab can present them in its UI.
However many psople miss that, and unsuccessfully check the logs
instead.
Address this by using a simplified version of gnome-shell's eslint
wrapper, so we can report results both on stdout and in a file
without re-running the linter.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/262>
We no longer have a separate classic theme that could(*) use
custom assets, so the file is now very officially a left-over.
(*) spoiler alert: The made-up property where the image was
used has been ignored by gnome-shell for years
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/260>
As gnome-shell is moving to ESM, it will now load extensions as
standard modules instead of using legacy imports. The change boils
down to exporting the Extension class as default, but we can also
start using standard imports for introspected modules now, so do
that at the same time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/259>
Disable() should restore the scheme preference that was used when
the extension was enabled, not when it was first initialized.
Even if it's unlikely to be relevant in practice, let's make sure
we save the correct state.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/257>
Now that gnome-shell supports a light style, people may want to
use it without forcing all apps to be light.
Add a small extension that switches the default to light, so the
shell follows the regular "dark style" preference.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/256>
Now that classic styling is based on color scheme instead of
a dedicated "classic" stylesheet, we should do the same for
extension styling, with the bonus that it also works with the
regular appearance setting outside the classic session.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/254>
gnome-shell now includes a light variant, and supports switching
between dark- and light styling at runtime.
That means we no longer have to build our own stylesheet, and can
instead just instruct gnome-shell to always use the light style
in the classic session.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/254>
