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
ES6 finally adds standard class syntax to the language, so we can
replace our custom Lang.Class framework with the new syntax. Any
classes that inherit from GObject will need special treatment,
so limit the port to regular javascript classes for now.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/30
Arrow notation is great, but as we only started using it recently,
we currently have a wild mix of Lang.bind(), function() and () => {}.
To make the style consistent again, change all anonymous functions
to arrow notation.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/30
Continuous integration is good, in particular when used before
merging a change to master as allowed by gitlab. And now that
we enabled some basic syntax checking of source files, we even
have something useful to test for ...
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/32
As a pure javascript project, building is really just a glorified
copy operation, so success doesn't even indicate that sources are
syntactically correct (a.k.a. "compile-tested"). We can at least
get some minimal testing by performing some basic syntax checking
when SpilderMonkey's JS shell is available.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/32
The steps for adding a new extension are clearly different in meson,
so update the instructions accordingly. Don't bother with keeping
the existing autotools steps - supporting both build systems in
parallel is just temporary, autotools is on its way out.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/31
We currently do have some Makefile magic to export zip files suitable
for uploading to extensions.gnome.org. As this is not easily replicated
in meson, add a small non-magic script for the same purpose.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/31
Over the years the list of extensions has become seriously outdated - a
number of extensions has long been removed, while others have been added.
With the switch to gitlab, the README is displayed prominently, so make
sure the list is accurate again.
"for each ... in" has been deprecated for a long time and won't be
supported in upcoming SpiderMonkey versions, so replace it with
"for ... of" instead.
Instead of copying a long function for a single changed line, wrap the
layout algorithm in a LayoutStrategy so the workspace code picks it
up without modifications.
https://bugzilla.gnome.org/show_bug.cgi?id=787934
Currently the injection to move title captions to the top depends on
the value of the setting at the time the extension is enabled.
Instead, do the injections unconditionally and query the setting
inside the function to pick up settings changes.
https://bugzilla.gnome.org/show_bug.cgi?id=787934
title._spacing is no longer defined, so we end up with bogus positions
when window-captions-on-top is set to true. Adjust the positioning to
do without that for now, though the whole extension could use a rewrite
to not copy everything-and-the-kitching-sink, or be killed off as yet
another extension from the original random collection that turned out
too expensive to keep dragging along ...
https://bugzilla.gnome.org/show_bug.cgi?id=787604
