We have an option to put a window list on each monitor, so we may have
more than one window picker toggle. We don't want each of those try to
toggle the window picker simultanuously, so move handling of the super
key directly into the picker.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/80
Now that we no longer hide the overview when the menu is opened,
it is possible to activate menu entries from the overview. Start
hiding the overview in that case, which is consistent with app
launching elsewhere.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/69
We don't want the "Activities" button in GNOME Classic, but the current
way of handling it is confusing:
- the button is hidden, but the corresponding hot corner
sometimes works (when the application menu isn't open)
- the button is effectively moved inside the menu, although
it's clearly not an app or category
- the apps-menu can be used independent from classic mode, in
which case removing the "Activities" button may not be wanted
Address those points by removing any handling of the activities button
from the apps-menu extension. We will remove it again from the classic
session via a session mode tweak.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/69
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
PanelMenu.Button is a bit weird in that it also "contains" its parent
actor. That container is supposed to be destroyed with the button, but
as we currently don't chain up to the parent class' _onDestroy(), we
leave behind an empty container every time the extension is disabled.
Fix this by adding the missing chain-up.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/75
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
gnome-shell moved to ES6 classes, which means the constructor is
no longer a regular method that we can swap out with an injected
version.
Instead, do our modifications in subclasses and use them to replace
the original classes.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/143
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
