Per-desktop overrides aren't limited to keys in org.gnome.mutter, so
we can use them instead of the alternate-tab extension to default to
the window switcher in the classic session.
https://bugzilla.gnome.org/show_bug.cgi?id=786496
GSettings now recognizes per-desktop overrides that can be used
to change schemas' default values for classic mode, so use that
instead of the separate override schema we currently use with
mutter's custom override mechanism.
https://bugzilla.gnome.org/show_bug.cgi?id=786496
As of the libmutter API version 3 MetaScreen does no longer exist.
Functionality that previously depended on MetaScreen has been moved
elsewhere (e.g. MetaDisplay or MetaWorkspaceManager etc).
https://bugzilla.gnome.org/show_bug.cgi?id=759538
This is a relatively recent addition to the standard we can use where we
don't care about the actual position of an element inside the array.
(Array.includes() and Array.indexOf() do behave differently in edge cases,
for example in the handling of NaN, but those don't matter to us)
We can only know about override settings that are provided by the
upstream GNOME or GNOME Classic sessions, but not any custom sessions
created by admins, users or distributions. Handle that case by falling
back to the original settings.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/62
All we are really interested in is mozjs' js52 utility for running
syntax checks - gjs has significantly more dependencies, so cut
down on time and bandwidth spent on downloading and installing
unneeded packages.
This cuts down the number of packages we install from 202 to 13,
and the download size from 133M to 17M.
Meson has a strict separation of source- and build directory, and
expects anything generated in the latter. That means that in order
to maintain our current setup - shipping the generated CSS in the
repo while also optionally updating it automatically when sassc is
found - we have to fight the build system to some extent, which makes
it less reliable than we would like.
Since we switched to sassc which is a more acceptable build-time
dependency than the original ruby-based tool, just drop the CSS
from the repo and unconditionally generate it from SASS if classic
mode is enabled.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/28
Most buttons appear in modal dialogs which keep their normal
appearance in the classic theme, except for the calendar's
"Clear All" which needs a dark text color to be readable on
the light background.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/26
We currently track window creation to decide whether the new window
should be moved or not. In order for this to work, the window must
already have been matched to the correct application, which is only
the case when the properties used for app matching were supplied
during window creation.
This is usually the case on X11, but never on wayland. To avoid this
issue altogether, stop listening for raw window creations, and instead
track when a window is added to an application we are interested in.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/33
While reading the configuration, processing it and iterating over the
configured apps to find a match isn't terribly expensive, but caching
the configuration in a map does save a bit of work, and makes for much
cleaner code in findAndMove().
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/33
