| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
This functions clears the clipboard if any of its contents becomes
potentially invalid.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are making the assumption that the clipboard data is always
correctly formatted. Given that the "x-special/gnome-copied-files"
doesn't necessarily have a defined specification and that some
other software programs seem to be passing bad data, we need to be
more careful about the assumptions we make.
Let's add a few more checks:
1) The first line must begin with "copy" or "cut"
2) All subsequent lines must either be a valid URI or an empty string
(after stripping out '\n')
3) If there are any errors in the clipboard, return an error rather
than an empty clipboard
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2539
|
| |
|
|
|
|
|
|
|
|
|
| |
It's possible that nautilus_clipbaord_from_string() receives an
empty string. When an empty string is received nautilus crashes
because g_str_equal() cannot handle the null value returned from
g_strsplit(). We could simply change g_str_equal() to g_strcmp0()
but that opens up the possibility for the for loop to give
unexpected results (it only checks for NULL starting at index=1).
Check if the results from g_strsplit()[0] == NULL and return early.
|
| | |
|
| |
|
|
|
|
| |
No visual result expected for now. This GtkTreeView-based view is not
here for long anyway. Just doing this to copy the approach into the
grid view next commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old implementation supported providing 3 clipboard targers:
- the "x-special/gnome-copied-files" MIME Type
- the "text/uri-list" MIME Type
- plain text clipboard
We would build slightly different strings for each target.
For pasting, only the first target was supported, but the provider
could be any other program, not necessarily ourselves.
In order to restore this non-local clipboard functionality, we need to
serialize content into these target types or deserialize into a GType.
- For the first one, we register our own custom [de]serializers,
which replicate the old implementation format.
- For the other two, we have GDK do it from GTK_TYPE_FILE_LIST.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
GdkClipboard is a new API very unlike the now-gone GtkClipboard.
It uses GValue for clipboard data, which allows in-process
operation to use the local data structures directly.
For this, extend our ClipboardInfo struct into a full blown
NautilusClipboard boxed type.
Non-local clipboard operation still needs reimplementation.
|
| |
|
|
|
|
|
|
| |
Before porting to GdkClipboard, and in order to get a clean diff,
let's start by removing functions definitions which deal with the
old GtkClipboard API and nothing specific with our custom content,
as well as wrapper to get clipboard from a widget, which now is
provided directly by GTK.
|
| |
|
|
|
|
|
| |
GTK 4 changes how clipboard is interacted with, compared to GTK 3.
Disable this code before the switch. It shall be reimplemented
once we are building against GTK 4.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After removing the non-default "icons on desktop" functionality from
nautilus, a gnome-shell extension was created as a substitute. This
extension needed to interoperate with nautilus for file operations,
but its access to clipboard was limited to plain text, so, in order to
ensure interoperation, nautilus had to use plain text clipboard only.
However, this temporary regression resulted in implementation details
leaking into the text clipboard, instead of a plain file path.
But now St.Clipboard can handle any type of clipboard content[1], the
extension will be able to handle any clipboard type, so we can finally
fix this regression on our side.
This reverts commit 1f77023b5769c773dd9261e5294c0738bf6a3115
and its fixup commit be53569b339b4494647758a9afa0fdd30184455b
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/634
[1] GNOME/gnome-shell@ec367623
|
| |
|
|
|
| |
There are some style issue since the last run. Let's run it again
before enabling style-check CI job.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Nautilus is supposed to clear items in the clipboard in case when
items moved by drag-and-drop were were present in the clipboard.
However, the item URI collision check algorithm compares moved (or copied)
items with themselves instead of clipboard contents, resulting in the
clipboard being cleared on every drag-and-drop operation.
Fix the algorithm to address this issue.
Closes: https://gitlab.gnome.org/GNOME/nautilus/issues/1235
|
| | |
|
| |
|
| |
What.
|
| |
|
|
|
|
|
|
|
| |
Somehow, magically, it can happen that the clipboard contains an empty
string, which wreaks havoc in convert_selection_data_to_str_list(),
since the loop counter goes from 0 to the number of lines in the data
string minus one. This commit adds a check for the number of lines and
returns early. Additionally, this introduces automatic cleanup for a
variable and fixes mismatched types.
|
| |
|
|
|
|
|
|
| |
Now that we have better integration with the shell extension, and it
simplifies regular clipboard handling.
A nice feature is that now you can perform operations on GEdit or any
other text editor by writing the correct commands :D
|
| |
|
|
|
| |
Some issues were fixed, and now we can rerun Uncrustify to format
correctly more part of the code.
|
| |
|
|
|
|
|
| |
The item list in nautilus_clipboard_is_cut_from_selection_data () is
never freed.
https://bugzilla.gnome.org/show_bug.cgi?id=774232
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were using a custom clipboard monitor, due to some old behaviour
in 2004 where not all X servers supported XFIXES, which allows to
monitor global clipboard changes between processes, which are needed in
Nautilus for copy, paste and link operations, and their availability
check.
Since Nautilus was a single process, it was working for most of the
time.
However recently we split the desktop in a different process, so we
were not able to correctly set the GDK action for clipboard, since
we were relying on sharing the same clipboard in the same process.
In order to fix this, this patch reworks the clipboard handling to a
more modern way, using the owner-changed signal present in XFIXES.
This fixes the clipboard changing between the desktop and Nautilus
and interproccess clipboard handling, fixes small corner cases, and
in the way this patch makes the code design and ownership of clipboard
more clearer.
https://bugzilla.gnome.org/show_bug.cgi?id=771046
|
| |
|
|
|
|
|
|
| |
And make the style of Nautilus the same for all files.
Hopefully we can fix all the style issues we can find in the next days,
so expect a little of movement on this.
https://bugzilla.gnome.org/show_bug.cgi?id=770564
|
|
|
And fix make distcheck.
Although libnautilus-private seem self contained, it was actually
depending on the files on src/ for dnd.
Not only that, but files in libnautilus-private also were depending on
dnd files, which you can guess it's wrong.
Before the desktop split, this was working because the files were
distributed, but now was a problem since we reestructured the code, and
now nautilus being a library make distcheck stop working.
First solution was try to fix this inter dependency of files, but at
some point I realized that there was no real point on splitting some of
those files, because for example, is perfectly fine for dnd to need to
access the window functions, and it's perfectly fine for the widgets
in the private library to need to access to all dnd functions.
So seems to me the private library of nautilus is somehow an artificial
split, which provides more problems than solutions.
We needed libnautilus-private to have a private library that we could
isolate from extensions, but I don't think it worth given the problems
it provides, and also, this not so good logical split.
Right now, since with the desktop split we created a libnautilus to be
used by the desktop part of nautilus, extensions have access to all
the API of nautilus. We will think in future how this can be handled if
we want.
So for now, merge the libnautilus-private into src, and let's rethink
a better logic to split the code and the private parts of nautilus than
what we had.
Thanks a lot to Rafael Fonseca for helping in get this done.
https://bugzilla.gnome.org/show_bug.cgi?id=765543
|
