All variables should be in camelCase, so configure the corresponding
rule to enforce this. Exempt properties for now, to accommodate the
existing practice of using C-style underscore names for construct
properties of introspected objects.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
gjs started to run eslint during its CI a while ago, so there is an
existing rules set we can use as a starting point for our own setup.
As we will adapt those rules to our code base, we don't want those
changes to make it harder to synchronize the copy with future gjs
changes, so include the rules from a separate file rather than using
the configuration directly.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/50
When destructuring multiple return values, we often use trailing commas
to indicate that there are additional elements that we are ignoring.
There isn't anything inherently wrong with that, but it's a style that's
too confusing for eslint - on the one hand we require a space after a
comma, on the other hand we require no space before closing brackets.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/49
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
While we have some style inconsistencies - mostly regarding split lines,
i.e. aligning to the first arguments vs. a four-space indent - there are
a couple of places where the spacing is simply wrong. Fix those.
Spotted by eslint.
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
Since template strings were added in ES6, string concatenation is
considered bad style. There's a catch though: xgettext currently
has a nasty bug concerning the combination of backticks and slashes.
Avoid that issue by building filenames with the corresponding GLib
helper function.
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
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
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
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
There are plenty of extension examples out there, no need to include
a sample extension that doesn't show-case any useful functionality
but puts additional burden on distributors to exclude it from packaged
extensions.
Ever since GNOME 3.8 when gnome-shell started to provide the window
switcher functionality itself, the extension has only existed to
change the default behavior of the alt-tab shortcut in the classic
session. Now that we achieve this behavior with a per-desktop override,
there's no longer a need for the extension, so remove it altogether.
Users who prefer the window switcher over the default app switcher
can use the regular keyboard settings to assign a shortcut to the
"Switch windows" action.
https://bugzilla.gnome.org/show_bug.cgi?id=786496
Window lists are per-monitor, so workspaces are implemented by
simply hiding all buttons that correspond to windows/apps on
other workspaces. That means we need to take the visibility
into account when handling scroll-events to switch through the
list, or else we'll end up switching "randomly" between workspaces.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/78
Florian Müllner
Pieter Schalk Schoeman
Charles Monzat
Ryuta Fujii
Piotr Drąg