The context menu in the overview includes actions for managing
favorites. Add those to the AppMenu class, but make it another
option as the actions would be slightly weird in the top bar menu.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
The top bar menu always corresponds to a running app, so it made
sense to include the 'Quit' item unconditionally. That won't be
the case for the overview context menus, so handle app state changes
and show/hide the item as necessary.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
Since commit fd0da9606f, we only show the "Open Windows" section
if there are at least two windows. That's another subtle difference
with the overview context menus, but while limiting the section to
a minimum of two windows makes sense where the menu always represents
a running app, it is useful to show the section even for single windows
in the dash/app grid.
Account for both uses cases by adding a corresponding option to the
constructor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
There's a subtle difference between the top bar menu and the app
icon context menus in the overview regarding the "Open Window"
section.
The former includes skip-taskbar windows, the latter doesn't. It
clearly doesn't make sense for the context menu to include windows
that aren't shown in the overview, but skip-taskbar windows are
likely also less useful in the top bar menu.
Just settle on the behavior of the context menus and move on.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
This is the expected behavior when activating a window or app. Until
now we could rely on the menu being hidden in the overview, but as
that is about to change, make sure the menu behaves as expected.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
App windows are ordered by recency, so a focus change (correctly)
triggers the ::window-changed signal. If we rebuild the section
immediately in response, the activating item will be destroyed
before the menu's ::activate handler, with the result that the
menu remains open.
Defer the section update in that case to allow the menu to process
the ::activate signal first.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
For now the menu is only used in the top bar, where we can assume
that it exists "forever". This won't be the case when we start
reusing it elsewhere, so make sure we clean up after ourselves.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
There is a big overlap between the app menu in the top bar and the
context menu of app icons. It makes sense to unify the two both
from a design- and from a code perspective, so split out the more
modern one into a separate module as basis for a shared class.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
There was a potential issue when suspend was inhibited and immediately
uninhibited again before the creation of the inhibitor has finished.
Then the new inhibitor would be kept active.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1927>
ScreenShield::_syncInhibitor() was closing (and recreating) the
inhibitor everytime it was called, even if no change was needed.
This gets called in various places, including on property changes in
the login1 dbus object. These happen by the time logind already started
suspending at which point new inhibitors can no longer be created. It is
only waiting for existing inhibitors to be closed, so closing the
inhibitor without a new inhibitor will cause the suspending to proceed
immediately if no other inhibitors are present. This can also happen
before the lock screen is shown, which will then complete after resume.
Fix this by keeping track of the expected inhibition state and only
create or close inhibitors if there was a change to that.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3736
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1927>
We have initTranslations() for binding an extension's
gettext domain, but nothing to help with using gettext
from an extension.
Such help would be useful though, as an extension that
calls textdomain() like a normal application would
inadvertently changes the default domain for the whole
gnome-shell process.
Instead, extensions have to use domain-specific versions
of the gettext functions:
```js
const Gettext = imports.gettext.domain('my-extension');
const _ = Gettext.gettext;
```
Make this a bit easier by adding those functions directly
to the extensions object when initTranslations() is called,
then expose helper functions for calling them.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2594
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1941>
Regex are a crude tool for analyzing whether some code *calls* a
particular function. Spidermonkey has Reflect.parse() that returns
the AST of the passed in code, which allows for a much more precise
check for javascript.
The old script is still used for C code, where i18n-affecting changes
are much rarer.
Based heavily on Philip Chimento's mozjs migration script at
https://gitlab.gnome.org/ptomato/moz60tool.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1941>
The value can not actually be null at that point, but it's too
hard to spot for tools like coverity:
- before setting view, we chain up to the parent's acceptDrop()
- that calls _canAccept(), which we override and check for the view
Still, and extra ? doesn't hurt, and hopefully will make the tooling
happy.
CID 351269
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1950>
There is now a location portal that provides a similar role
as our agent. Settings supports that portal in its application
panel, which allows users to revisit their choice later.
Unfortunately it uses a different permission store table, so
any permissions granted (or denied) through our agent won't
show up there.
To change that, switch to the same table as the portal/Settings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1945>
On startup desktop-icons-ng Wayland windows have skip-taskbar==FALSE so
initially pass `_isOverviewWindow` and they get added to the overview,
which is confusing to users. However almost immediately after that they
get `meta_wayland_client_hide_from_window_list` and are removed from
future overviews. So now we respond to `notify::skip-taskbar` immediately
and prevent desktop-icons-ng appearing in the startup overview too.
This is messy and ideally we'd like to know the window type immediately
on creation, but that option only exists in X11 and not Wayland.
https://gitlab.com/rastersoft/desktop-icons-ng/-/issues/137https://bugs.launchpad.net/bugs/1936643
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1925>
At least the last stable release of gjs has an issue with async
handlers for custom (i.e. defined in JS) GObject signals.
The handler still works, but evoking it prints the following warning:
JS ERROR: Error: Could not guess unspecified GValue type
We can avoid the warning by using the addAction() convenience
method, which makes for a small nice cleanup anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4531
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1938>
