PopupMenuManager's grabHelper starting from gnome-shell@7bb84da must be
an actor, so pass it explicitly instead of expecting the shell to do it
for us.
This fixes an error during pushModal that was causing a grab not to be
released.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/68
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
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
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
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
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
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
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.
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
The window context menu contains minimize, maximize and close items
that are currently enabled unconditionally, regardless of whether
the window indicates support. Respect those hints by updating the
items' sensitivity every time the popup is shown.
https://bugzilla.gnome.org/show_bug.cgi?id=783601
The top bar now uses a translucent style when no windows are in its
proximity. As translucency looks odd in some situations (in particular
with maximized windows), we don't want to pick it up unconditionally.
If someone fancies to integrate with the top bar's proximity tracking,
they are welcome to have a go, but for now we just restore the former
solid style unconditionally.
There's no need to show the workspace indicator at the right
corner of the window-list if there's just a single workspace
AND the workspace creation is static. This saves us a bit more
of space.
https://bugzilla.gnome.org/show_bug.cgi?id=777504
We currently assume that the application associated with a particular
window is fixed. While this holds true for almost every application,
there are some cases of multi-app-packages like LibreOffice where
windows may change the properties used for application matching at
runtime. Catch those cases to make sure we display the correct icon
when the window shifts applications.
https://bugzilla.gnome.org/show_bug.cgi?id=771731
Independent from the grouping mode, the window-list currently shows
up as a series of "push buttons" in screen readers, which is obviously
not useful, so point to the correct labels.
https://bugzilla.gnome.org/show_bug.cgi?id=755223
It is odd to consider windows that are not shown in the window list
for app sorting, in particular when switching between grouped and
ungrouped mode, and when a long-lived window like the DESKTOP is
present.
https://bugzilla.gnome.org/show_bug.cgi?id=753055
Just like the top bar, the window list should scale according to
the font scaling factor, so convert the existing pixel sizes into
font-relative ones.
https://bugzilla.gnome.org/show_bug.cgi?id=703585
Marco Trevisan (Treviño)
Florian Müllner
Jonas Ådahl
Piotr Drąg
Felipe Borges
Jakub Steiner