The screen recording menu entry will use this to check if a screencast
is currently active and to stop the screencast.
Use a GObject property so we can bind to notify; specifically we'll bind
the visibility of a screencast area indicator.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2103>
Currently does nothing. When we're in screencast mode, we hide the
screenshot preview because screencast doesn't start until the capture
button is pressed.
The window selection is currently left as is, but it should probably be
changed to something closer to a real overview, showing windows in
real-time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2103>
The cursor texture, scale and position is captured separately and
overlaid on top of the preview, and on top of the final screenshot
image. This allows toggling it on and off post-factum.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1954>
Allow switching the screenshot mode by pressing the "s", "c", or "w" key. Also
implement arrow-key navigation between monitors in the screen screenshot mode
and between windows in the window screenshot mode.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1954>
UIWindowSelectorLayout is a stripped-down subclass of WorkspaceLayout
(we don't have to deal with windows disappearing or appearing or
changing size). UIWindowSelectorWindow is a heavily stripped-down
version of WindowPreview. UIWindowSelector is analogous to the Workspace
class.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1954>
Commit dd2cd6286c restricted callers of the screenshot methods to
portal implementations, gnome-settings-daemon and gnome-screenshot.
That restriction does make sense for the actual screenshot methods,
but `PickColor` is actually used by GTK in its color picker (and
therefore may be called from arbitrary applications).
Fix this by unrestricting access to `PickColor` again. Considering that
the method is always interactive, it's not very privacy/security-sensitive
anyway.
https://gitlab.gnome.org/GNOME/gtk/-/issues/4283
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1990>
Add a "screenshot-taken" signal from the screenshot service's internal C
implementation, and use that to trigger the camera flash visual effect
and the click sound, allowing them to run in parallel with the PNG
compression instead of waiting until the file is complete to start.
This significantly improves perceived latency on high res setups such as
4K, 5K, or dual 4K screens.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/512
Co-authored-by: Brion Vibber <bvibber@wikimedia.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1658>
On my local jhbuild setup some local stuff is not set up and
there's no pictures folder. This fixes a regression where it
blew up instead of saving to the home dir in this situation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1658>
We currently only remove the screenshot operation from the shooter
map if the color pick operation completed successfully, but not if
it was cancelled. As a result, we now reject any further requests
from the same sender because we assume that there is an ongoing
operation.
Fix this by moving the cleanup to a finally clause that runs for
both code paths.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1288
Right now _createScreenshot() returns a tuple that indicates failure
when a sender requests a screenshot operation before a previously
started operation finished.
However that doesn't work for the PickColor() method, as it uses a
different return type than the other methods.
Address this by returning an error instead, which works in any case;
arguably trying to start multiple operations in parallel is an error
by the caller more than it is a failed operation anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1288
With color picking implemented in the compositor, we
can do better than letting the user pick a pixel with
the crosshair cursor, and present them with a preview
of the color that will be selected.
Do this by replacing the cursor with a custom icon and
apply a recoloring effect, where we replace a given color
with the color of the currently hovered pixel (similar
to a green screen).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/451
Promises make asynchronous operations easier to manage, in particular
when used through the async/await syntax that allows for asynchronous
code to closely resemble synchronous one.
gjs has included a Gio._promisify() helper for a while now, which
monkey-patches methods that follow GIO's async pattern to return a
Promise when called without a callback argument.
Use that to get rid of all those GAsyncReadyCallbacks!
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1126
Commit da537cda43 moved the Shell.Screenshot API to GIO's async pattern,
but we never set the GError passed to the *_finish() functions and only
indicate failure by returning FALSE.
The expected behavior is to throw an error in that situation, so make sure
we do that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1123
String.prototype.substr() doesn't support a negative length value
(to subtract from the full length), so we end up with a filename
of '' when hitting that code paths (a relative filename with '.png'
suffix).
Fix this by switching to String.prototype.replace() instead.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2091
