| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
In gtk3 Nautilus used to construct the uri-list.
nautilus_uri_to_native_uri() was used to ensure that apps that didn't
have gvfs access could access the dropped file. Now gtk4 constructs
the uri-list, so a similar process is handled on the gtk side.
Related: #2632
|
| |
|
|
|
|
|
|
|
|
|
| |
Now that we are bringing the gnome-user-share extension
into Nautilus itself, we need the ability to check
if gnome-user-share is installed. GNOME Settings
does this by checking the schema. Let's use the same
code that Settings uses.
This doesn't work within sandboxes, so if we are
sandboxed always return TRUE;
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It compares the filesystem type identifier with a hardcoded list of
remote types introduced in 2015.[0]
The filesystem::remote attribute has been introduced[1] to handle this,
and we have been using it[2], but kept the hardcoded list in order to
workaround issues with GLocalFile not setting this attribute correctly.
Now that these issues have been fixed[3], we can finally drop it.
[0] d3e1a71c6377343af5d61d6ded7bc4f53dfeaf53
[1] https://gitlab.gnome.org/GNOME/glib/-/commit/e57355b055217b067cd1a71340f7ea47e51d4aae
[2] 99f55748ef69a68df86b9a039998ee576d59b898
[3] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1534
|
| |
|
|
|
|
|
|
|
|
|
| |
Querying the file cache in is_recursive_search() does not guarantee that
the file system field will be populated with a value, and somehow
results in data races, in turn resulting in random crashes/file list
corruption.
Hopefully fixes https://gitlab.gnome.org/GNOME/nautilus/issues/640,
closes https://gitlab.gnome.org/GNOME/nautilus/issues/632 and resolves
https://gitlab.gnome.org/GNOME/nautilus/issues/602
|
| |
|
|
|
|
|
|
|
|
|
| |
A method to query maximum filename length has been introduced by
commit a5520fd8930910ffa686232f3fc92325fe47c64e
However, Ernestas has noticed that another implementation was already
present in nautilus-file-operations.c
This commit will replace both with a file-utilities function, which
takes ideas from both implementations.
|
| |
|
|
|
|
| |
Just use settings_search_get_recursive_for_location to prompt to the user
what's going to happen, although this might not be 100% certain, if a sub-dir
is actually a network-mounted folder.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Use a list of cases to define when the recursive search should be done, instead
of a simple true/false boolean.
A part from the self-explanatory cases `ALWAYS` and `NEVER`, the `IF_INDEXED`
option permits to any search engine that uses an indexed-search to return
results from subfolders of the search location.
One case we want to address, is the shell-search provider, that should not perform
recursive searches, but it could return values from subfolders of the user home
if the search is executed by search engines like tracker.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
With the new search bar design, the search information displayed under
they query editor was not working properly.
Instead, the new design says that the information should be displayed
in the view itself, as a top banner.
This work implements the new design and fixes several issues of sizing
due to the wrong position of the search information label.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/403
|
| | |
|
| |
|
|
|
|
|
| |
Since commit 74dd9c9f72002d482c898a704bb5b95655e35e08, this function
is undefined and this constant is unused.
Let's drop them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
None of this is currently used.
Also, since the desktop_is_home_dir setting was removed in
commit 5ab3050f22da718264a35e61ada4be1a386a6e2d, the desktop dir is
always XDG_DESKTOP_DIR. Thanks to that, we can simply use this instead:
nautilus_file_is_user_special_directory (file,
G_USER_DIRECTORY_DESKTOP)
Therefore, remove the obsolete API.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The traditional include guards are not as easy to handle
and require extra thought into the names.
Pragma once is an easier, more contributor friendly approach.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/294
general: Remove include guards in favor of pragma once
The traditional include guards are not as easy to handle
and require extra thought into the names.
Pragma once is an easier, more contributor friendly approach.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/294
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When hacking on Nautilus, it is very inconvenient to have to close any
running instance before running the built version. This commit enables
running three different instances by changing the application ID.
Beside the default “profile” is one crafted for stable flatpak
releases and one for development. The stable flatpak profile adds an
identifying mark to the about dialog to aid collecting information in
bug reports. The development profile is that plus additional styling to
help visually identify the development instance. It also will be used
when generating Flatpak bundles with the help of CI.
Generally, the implementation is slightly hacky to allow all the
different workflows, spanning from regular installations to GNOME
Builder flatpak builds, as each comes with its own quirks.
|
| |
|
|
|
|
|
|
| |
It was a mix of both terms, given that tracker uses 'favorite' but we
use 'starred' in the UI. Since the part that interact with tracker is
minimal, is better to be consistent with the UI.
This renames 'favorite' to 'starred' except the tracker queries.
|
| |
|
|
|
|
|
|
|
|
|
| |
These locations are listed in the sidebar already. Bookmarking duplicates them.
We already disable bookmarking Home, Favories, XDG User Firs, and Other Locations.
Do the same thing for Recent and Trash.
As a side effect, this will disable bookmarking child folders inside Trash.
Fixes: #189
|
| | |
|
| |
|
|
|
|
|
| |
Add option to make files Favorite, by either toggling a star in the
list view, or from the context menu.
https://bugzilla.gnome.org/show_bug.cgi?id=786039
|
| |
|
|
|
|
| |
This allows drag and dropping files from network shares in Thunar
to other applications that don't handle native URIs (Claws Mail,
Chromium, Firefox...)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now archives were managed only if activated from Nautilus itself
and if a setting was set.
There are two main problems with this.
1- Archives opened in other apps cannot be handled by Nautilus
2- Users cannot use the regular mime type handling for setting Nautilus
as the app handling archives, or unsetting it.
This patch add support for archives mime types handled by gnome-autoar
and removes the UI and setting used in the previous version.
https://bugzilla.gnome.org/show_bug.cgi?id=771424
|
| |
|
|
|
|
| |
It was removed long ago
https://bugzilla.gnome.org/show_bug.cgi?id=771424
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
'Other locations' is already listed in the sidebar. So there is no
need for allowing the user to bookmark 'Other Locations'.
This commit makes the bookmark button in toolbar insensitive for
'Other Locations'.
https://bugzilla.gnome.org/show_bug.cgi?id=771163
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Renaming multiple files at once has been a missing feature in Nautilus
for a long time. This patch implements that feature in the following way:
This operation is launched in the same way as the rename one, when the
selection has more than one file.
When the batch renaming is launched, a dialog is shown, offering two
modes.
In the first mode, the user can use metadata (if available), numbering and
original file name tags to create the new names. Between the tags, there
also can be written normal text, which will be added in the new names. If
numbering is used, the order of the files can be modified by using several
criteria.
In the second mode, the user can replace an existing part of the name.
https://bugzilla.gnome.org/show_bug.cgi?id=768311
|
| |
|
|
|
|
|
| |
The function works with strings instead of GFiles. Replace it with a function
that generates unique files in a directory using GFiles.
https://bugzilla.gnome.org/show_bug.cgi?id=768646
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
New Folder with Selection currently doesn't offer a folder name. It
would be better if it suggested a folder name based on the files that
are selected.
With this change, it now looks for a common filename prefix of the
selected files, and pre-populates the folder name entry with that. If no
common prefix is found that is greater than 3 characters long, the
folder name entry will be left blank.
https://bugzilla.gnome.org/show_bug.cgi?id=747907
|
|
|
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
|
