There are multiple different places where we activate an app action,
but none set the correct activation token. Therefore this adds an async
method to to call `ActivateAction` on `org.freedesktop.Appliaction`
with the correct activation token/startup id as platform data.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3198>
We auto-close FDO notifications when the sender leaves the bus,
given that the protocol was created without persistency in mind
and any action will become invalid.
However that broke when moving the public-facing implementation
into a separate service, as we now track the (always running)
service instead of the original sender.
Fix that by forwarding the sender to the internal implementation
via a private hint, just like we already do for the PID.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3204>
The hint is a private implementation detail between the public
and internal services, not something anybody else should set
(*cough* libnotify *cough*).
Prefix the name to hopefully make that clearer.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3204>
Both timestamp and options parameters have been unused since
the switch to Clutter.grab(), so remove them.
Stop using Params.parse(), so that code that still passes the
parameters doesn't throw an error.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3195>
It was added in commit 48fb16b570 for the lock screen, but that
hasn't been based on ModalDialog for a long time.
It doesn't appear that anything else ever used the parameter,
so just remove it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3195>
Currently extensions can only be locked down completely by
restricting the `enabled-extensions` key via dconf.
This is too restrictive for environments that want to allow users
to customize their system with extensions, while still limiting
the set of possible extensions.
To fill that gap, add a new `allow-extension-installation` setting,
which restricts extensions to system extensions when disabled.
As the setting is mainly intended for locking down by system
administrators, there is no attempt to load/unload extensions
on settings changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3180>
Since the last commit, we have infrastructure in place in the ScreencastService
to blocklist pipelines which crashed the recorder.
If such a crash happens a few minutes into a screencast, we can't do any better
than telling the user about the problem and encouraging them to try again (with
the faulty pipeline now blocklisted).
If the crash happens while starting the recording though, we can actually do
better: We can try to auto-restart the ScreencastService ourselves, and the
recording might still succeed without the user noticing anything. So retry
that start of the recorder for two more times, and then finally give up.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2976>
When gstreamer crashes during recording, it pulls the whole screencastService
down with it.
These crashes are typically caused by the gstreamer pipeline that's in use,
so to avoid running into them again and again, we can blocklist the last
used pipeline in case the recorder didn't shut down (aka crashed) last time.
To store this state, create a file (gnome-shell-screencast-pipeline-blocklist)
in the XDG runtime dir and store the ID of the current pipeline in that file
before we try to start.
Now when we crash while running the pipeline, the entry in that file will stay
around and we'll pick it up on the next start of the screencastService as a
blocklist.
When the recording was successful on the other hand, we'll call
`this._updateServiceCrashBlocklist([...this._blocklistFromPreviousCrashes])`
and remove the new entry from the file again before shutting down the recorder.
In addition to that, we can now encourage the user to try recording again
after a crash happened. Adjust the failure notification a bit to say
"please try again".
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6747
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2976>
Since we now propagate error types back to gnome-shell now, let's start
with showing a special error message in case the disk ran out of space,
which is probably the most typical error.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2976>
When the screencast fails to start, we currently don't really inform the
user, other than the red screencasting indicator in the panel going away.
Re-use the failure handling paths to also show a notification when the
screencast fails to start. The notification in this case obviously should
not have an action to open a file (there is no file), so make that depend
on whether this._screencastPath is set and unset the path.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2976>
We'll be using hardware encoding for screencasts soon, so we'll likely see
more things go wrong in the future, including crashes of the whole
screencastService. To deal with this, we'll introduce logic to blocklist
certain recording pipelines in case of failure and also add some logic
to retry the recording automatically.
To allow for better messaging to the user in those failure cases, we want
to be aware in gnome-shell, what exactly the error in the recorder was.
So propagate the most common types of errors that can happen in the
ScreencastService to gnome-shell using the new DBusError module.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2976>
Commit 932ccac1 changed Source to use a regular constructor
instead of `_init()`.
Unfortunately that results in ordering issues for subclasses
that override `_createPolicy()`, if that method needs to access
any properties that are set in the constructor (as `this` is
only available after chaining up to the parent).
We can fix that by simply setting the policy from the constructor,
instead of relying on some overriden method being called.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3170>
We have several places where we create an application policy
from an app if possible, and fall back to a generic policy
otherwise.
Make that more convenient by adding a small helper method.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3170>
Since commit 932ccac1c27, the Source constructor takes a
properties object instead of individual arguments.
That means that the policy may now be set through a construct
property, and we shouldn't override it if that was the case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3170>
This drops all subclasses of `MessageTray.Source` that were used to
display system notifications. Now the `Source` returned from
`MessageTray.getSystemSource()` is used.
Ensure also that properties and methods that where set on the `Source`
are moved to the `Notification` object itself.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3156>
Extensions like dash-to-dock use set_icon_geometry() to window.
This changes the dest and scale of ease animation of minimize and
makes it looks very strange. By setting dest opacity to 0 the animation
could be more natural.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2968>
Screencasts can be disabled for various reasons:
1. the service is not available (missing plugin etc.)
2. screencasts are not allowed by the session mode
(lock screen etc.)
3. the UI is invoked in screenshot-only mode (portal)
Currently each of those conditions is handled in a different
code path, which means that later conditions can re-enable
the button.
There's also an inconsistency whether disabling the button
is done via visibility or reactivity, which still allows
toggling the hidden button via shortcuts (although a hidden
button means that screencasts aren't supported at all, so
nothing will be recorded in that case).
Address this by updating the button from a dedicated function.
Fixes: 671df28a50 ("screenshot: Only handle mode-switch shortcut when
supported")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7358
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3155>
