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>
This object contains only the `title` and `icon` of a
`MessageTray.Source` which allows using it for sources
that aren't notification sources like mpris.
The old `MessageTray.Source` isn't renamed to something
less generic to not break API. Once we have a good reason
we should rename it to something more specific.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3103>
Even though the comment in the code says that sources are reused even
thought the app title has changed this is actually not the case. Therefore
when ever the app title of a notification changes a new `Source` is
created. Therefore there is no point in setting the app title again.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3103>
As the notification redesign affects the API anyway, we can just
as well use the opportunity to modernize the code.
Turning the icon into a GObject property means we no longer need
a custom signal for change notifications, and the icon becomes
usable in bindings.
Since setting an `GThemedIcon` is common this also adds a convenience
property to set the icon name directly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3103>
They use API from Clutter.Rectangle which hasn't been used in the
magnifier since commit c815979f, and has since been removed from
Clutter altogether.
Since the methods are unused, remove them instead of fixing them.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2037>
If something grabs the key focus while a modal is pushed, keeping
key-focus on that actor seems like the smarter thing to do than setting
it back to the last focus after the modal gets popped again. So check if
the key focus actor that we set when pushing the modal got changed when
popping that modal, and if it got changed, simply don't touch key focus.
This fixes a bug with the close dialog, where key focus isn't correctly
set to the dialog after alt-tabbing to a window showing a close dialog.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/786>
When setting the key focus to `this._dialog`, the default button is not
automatically focused and no button has key focus.
Use the `initialKeyFocus` property of the dialog instead, and set focus
to the default button if the dialog is not already focused.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/786>
