When there is a new owner but there is no matching mime type we clear
the saved mimetype and the saved clipboard but an outstanding async
meta_selection_transfer_async can set the saved clipboard.
Abort the async transfer when we have a new owner.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3678>
The precondition checks in meta_selection_source_memory_new can return
NULL if the mimetype is NULL but callers expect the error to be set when
NULL is returned.
Let's just make sure we never call it with a NULL mimetype.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3678>
MetaSelectionSourceMemory currently uses GBytes for its underlying data.
This can cause memory overhead when large items, such as HD images, are
stored in the clipboard. This commit changes the underlying data
structure to a MetaAnonymousFile object, which writes to memfd instead
of heap. When reading, MetaSelectionSourceMemory will create a
Gio.UnixInputStream from the file descriptor generated by
MetaAnonymousFile. We subclass the UnixInputStream as
MetaUnixInputStream, to override the stream's close_fn function so
that it invokes meta_anonymous_file_close_fd when the stream terminates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3551>
Dropped obsolete Free Software Foundation address pointing
to the FSF website instead as suggested by
https://www.gnu.org/licenses/gpl-howto.html
keeping intact the important part of the historical notice
as requested by the license.
Resolving rpmlint reported issue E: incorrect-fsf-address.
Signed-off-by: Sandro Bonazzola <sbonazzo@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3155>
As with other parts, make objects have the ability to walk up the
ownership chain to the context, to get things like the Wayland
compositor or backend instances.
Contains these squashed commits:
display: Don't get backend from singleton
window: Don't get backend from singleton
keybindings: Don't get backend from singleton
workspace: Don't get backend from singleton
display: Don't get Wayland compositor from singleton
selection: Add display getter
context/main: Get backend directly from the context
clipboard-manager: Don't get display from singleton
stack-tracker: Don't use singleton MetaLater API
startup-notification: Hook up sequences and activations to display
This allows using context aware API directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
When an app disappears after some data from it has been copied to the
clipboard, the owner of the clipboard selection becomes a new memory
selection source. The initial reference this new selection source is
never unref'ed, which leads to this being leaked on the next clipboard
selection owner change.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1293
Support for them appears to be way less common than e.g. png, which is
currently the preferred format from Firefox, Chromium, Libreoffice and others.
Adopt to that fact.
As a side effect, this works around a bug observed when copying images in
Firefox on Wayland.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1141
Most usually, applications either expose clipboard content either as text
or as images, so the prioritization here is pointless. However there's some
outliers like LibreOffice Calc which exports content as both image and text
formats (besides other internal ones).
In that mixed case, we probably prefer to keep text formats, rather than
image based ones.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/919
This is a simple clipboard manager implementation on top of MetaSelection.
It will inspect the clipboard content for UTF-8 text and image data whenever
any other selection source claims ownership, and claim it for itself
whenever the clipboard goes unowned.
The stored text has a maximum size of 4MB and images 200MB, to prevent the
compositor from allocating indefinite amounts of memory.
This is not quite a X11 clipboard manager, but also works there.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/320