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
When overriding an upstream method, copying the original method code
should always be a last resort, as the two code bases tend to get
out of sync and it often becomes hard to spot the modifications done
by the override. Both those issues can be avoided when figuring out
a way to split out the modifications and call the unmodified upstream
method - we are in luck with our checkWorkspaces() override, as we
can trick the upstream method into not removing workspaces we want
to keep instead of copying the method altogether.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/33
Trying to dispose a proxy object before it has been properly
initialized triggers an "uncatchable exception", which gjs
treats as a fatal error since commit c7bdcaab4. We only have
anything to clean up once the proxy is initialized anyway, so
don't force dispose() before that.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/44
On wayland, the properties that are used for application matching
are generally set after the window has been created, so it is
normal that buttons start with the fallback icon. While we already
track the properties that are relevant for app matching, our signal
handler may run before the window is matched to its app.
Make sure the WindowTracker gets to process those signals first by
using connect_after() for our own handlers.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/10.
The description of the `enable_extensions` was wrong since it
changed to the `array` type, because the extension separator
is now a comma instead of space.
meson 0.44 features a new option type called `array` that allows
more than one string to be passed.
This feature fits perfectly the `enable_extensions` option needs,
so it has been changed to be an `array` type. the option has not
been limited to a set of choices to avoid duplication.
After replacing Lang.Class with ES6 classes and adopting arrow notation
for anonymous callbacks, we only use the Lang module to bind `this` to
named callbacks. However since ES5, this functionality is already provided
by Function.prototype.bind() - in fact, Lang.bind() itself uses it when
no extra arguments are specified.
So just use the built-in function directly instead of the wrapper.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/30
