We mostly use the regular == and != comparison operators over their
type-safe === and !== counterparts. This is about to change, but there
are some places where we don't care whether a value is null, undefined
or 0; just check for falsiness there instead of using operators, so
we can start to consistently use the type-safe operators everywhere
else in a follow-up commit.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/91
Array destructuring has been supported by gjs/mozjs for quite some time,
so we are already using it heavily where it makes sense.
However one place still sneaked through where using destructuring makes
sense, as the element's position has semantic meaning (instead of just
making it the first, second, ... element).
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/91
Invoking functions via Function.prototype.apply() and .call() is
less performant than a regular function call, and makes code harder
to read.
Before ES6 there was no other way of writing a function with variadic
arguments, but since we now have the spread operator, we can use that
as the better alternative.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/91
The extension currently assumes that we have the "Activities" button
at the left of the top bar. This is currently true, not only in the
regular session, but also in GNOME classic where the button is hidden
(but still present).
However this is about to change: We will stop taking over the button
from the apps-menu extension, and instead disable "Activities" from
the session mode definition.
Prepare for this by adding the places menu before the application menu
instead of assuming a hardcoded position.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/69
The coding style of using double quotes for translatable strings
and single quotes otherwise is unnecessarily complex and cannot
be enforced with an eslint rule.
Simply use single quotes consistently for all strings.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/57
Instead of keeping the first property on the same line as the opening
brace and aligning the properties, use a four-space indent. This brings
us closer to gjs' coding style, and as a bonus helps keeping lines in
the soft 80 character limit.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/57
Braces are optional for single-line arrow functions, but there's a
subtle difference:
Without braces, the expression is implicitly used as return value; with
braces, the function returns nothing unless there's an explicit return.
We currently reflect that in our style by only omitting braces when the
function is expected to have a return value, but that's not very obvious,
not an important differentiation to make, and not easy to express in an
automatic rule.
So just omit braces consistently as mandated by gjs' coding style.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/57
String concatenation is considered bad style after ES6 added
template strings. The latter is the replacement we generally
want, except where the aforementioned xgettext bug would trip
over the backtick/slash combination.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/49
We currently use a consistent style of not adding spaces in catch
clauses, however that's inconsistent with the style we use for any
other statement. There's not really a good reason to stick with it,
so switch to the style gjs/eslint default to.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/49
Now that PanelMenu.Button was made an StWidget subclass, the destroy()
method actually maps to the ClutterActor method, and overriding it
results in warnings when the extension is disabled. So instead, use
the existing ::destroy handler.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/113
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)
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
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
Florian Müllner
Piotr Drąg
Rémy Lefevre
Alexander Rüedlinger