gnome-shell started transitioning to gjs' object spacing rule,
i.e. `{foo: 42}` instead of `{ foo: 42 }`.
We have a much smaller code base than the shell and aren't using
a secondary "allowed-but-deprecated" configuration that allows a
gradual transition, so just pull the switch and update to the new
style.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/240>
Limiting the action to the row that changed instead of the list as
a whole makes it easier to only update the changed value and not
recreate the entire list.
This doesn't make a difference right now, because we carefully sync
the list to reuse existing rows, but we are about to back the list
with a GListModel instead of updating it manually.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/218>
As a side-effect of supporting class fields, regular constructors
now work in GObject subclasses. Using _init() still works and
there's no functional difference, but it's simply much nicer
to use the same syntax for all classes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/215>
Since commit a6ee142f21, the extension archives that are uploaded
to extensions.gnome.org only contain strings that are relevant for
the extension, not all translations from all extensions.
Unfortunately all extensions still share a common gettext domain,
so the extension with the last bind_textdomain() call wins and
leaves the others without translations.
We'll address this by using distinct domains when not installed
system-wide. That becomes easier if there is a canonical place
for the text domain, with the existing metadata key being the
natural choice.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/issues/335
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/179>
This fixes a particular case of mutter#992.
Although gnome-shell will also be softened to not crash in future, it's
also a good idea for the extension to explicitly decide how it wants to
handle windows that are already on all workspaces.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/157>
We modify gnome-shell's workspace tracker to only remove empty
workspaces from the end. However we currently don't take into
account that sticky windows appear on all workspaces, so those
are preventing any workspace from getting removed at the moment.
Exclude them when determining whether a workspace is empty to
get the expected behavior.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/135
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
As arrow functions have an implicit return value, an assignment of
this.foo = bar could have been intended as a this.foo === bar
comparison. To catch those errors, we will disallow these kinds
of assignments unless they are marked explicitly by an extra pair
of parentheses.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/91
ES6 allows to omit property names where they match the name of the
assigned variable, which makes code less redundant and thus cleaner.
We will soon enforce that in our eslint rules, so make sure we use
the shorthand wherever possible.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/91
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
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
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
Florian Müllner
Daniel van Vugt
Jonas Ådahl