Nautilus is a file manager, so we should star files.
Previously we starred the content resources extracted by Tracker Miner
FS, instead. This had the advantage that the stars would follow file
renames. It had the downside of being more complex and limited in
which files can be starred. In Tracker 2.x, the feature only worked
in folders indexed by Tracker Miner FS. With Tracker 3.x, it was
additionally limited to files where Tracker had extracted metadata
-- mainly just documents and media files.
This commit takes the simpler approach of storing the star against
the file URL. All files can now be starred, and stars will no longer
persist when a file is moved or renamed.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/160
This means the Nautilus flatpak will be able to use Tracker on systems
which don't have Tracker 3 available on the host. It comes at a cost of
increased resource consumption inside the Flatpak due running an extra
indexer process there.
Mostly the port is straightforward, we connect to tracker-miner-fs
explicitly over D-Bus instead of the centralized tracker-store daemon
we connected to previously.
The search-engine-tracker test is now isolated from the user's real
Tracker index using the `tracker-sandbox` script provided by Tracker,
and it lets tracker-miner-fs index the test file rather than trying
to synthesize the expected database contents.
There are more changes in nautilus-tag-manager.c. Until now, starred
file information was stored in the tracker-miner-fs database. This has
some downsides, firstly the data is deleted if someone runs `tracker
reset --hard`, secondly it isn't possible to do this from inside a
Flatpak sandbox with Tracker 3.0. because the
This commit changes the NautilusTagManager to set up a private
database inside XDG_DATA_HOME/nautilus/tags. This stores the starred
file information. The database is managed with Tracker, which allows us
to continue using the rename-tracking that tracker-miner-fs provides.
The same limitations apply as before that only files in indexed
locations can be starred.
The list of releases is outdated, which is probably why GNOME Software and
"flatpak info" shows version 3.32.1 for our nightly bundles, although the
About dialog shows something completely different. Let's replace the list of
outdated releases with just the current one. Also add comment in meson.build
to not forget about it next time.
Based on patches from Felipe Borges for other apps. Quoting him:
The GNOME Shell search results are forwarded from the results of
GLib's g_desktop_app_info_search() function, which matches the
Name, Exec, Keywords, GenericName, X_GNOME_FullName, and Comment
keys from desktop files[0].
Since Totem is now named "Videos", a query for "totem" would
match the "Exec" key and present the application in the search
results as expected. Unfortunately that doesn't happen for Flaptaked
Totem, which would get its desktop file "Exec" key overwritten to
something such as Exec=/usr/bin/flatpak run --branch=stable
--arch=x86_64 --command=totem org.gnome.Totem --new-document
This way, searching for "totem" when only the Flatpaked version
of it is installed returns no results. Searching for "Videos"
presents the application as expected.
Its been proposed in GLib to parse the "Exec" key for searches
but that was rejected[1] because it would imply establishing an
API which assumes that the command line behavior of Flatpak would
be stable/never-change.
A fix was proposed in Flatpak directly[2] but it was rejected,
leaving us with the only option of adding the historical/legacy
application names to the "Keywords" key in their desktop files.
Many users, such as myself, have the "muscle memory" of search
for the old application's name, such as "totem", "gedit", "evince".
Although I agree that the new names should be presented to new
users and that the old ones shouldn't be visible in UI, it makes
sense and little effort to support the search for the old names IMO.
[0] https://gitlab.gnome.org/GNOME/glib/blob/master/gio/gdesktopappinfo.c#L378
[1] glib#1706
[2] https://github.com/flatpak/flatpak/issues/2749
Add new version of FileOperations interface. This versions adds
PlatformData argument to all methods. Currently supported arguments
are parent-handle and timestamp.
This change is necessary for proper focus handling.
https://gitlab.gnome.org/GNOME/nautilus/merge_requests/504
C++ comments ("//") are converted to C comments ("/* */"), but they
are not grouped together. So, each line is enclosed by "/* */". Let's
add cmt_cpp_group and cmt_c_group options to ensure that the single
line comments are grouped together.
Let's add "indent_ternary_operator = 1" to our uncrustify.cfg in order
to prevent the following unwanted change:
list = back ? nautilus_window_slot_get_back_history (self->window_slot) :
- nautilus_window_slot_get_forward_history (self->window_slot);
+ nautilus_window_slot_get_forward_history (self->window_slot);
Files is name which is used in the About dialog, the in Desktop file
and on the website, thus we should use it also in the AppData file as other
projects do.
This fixes the following downstream bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1725120
Keep the ID as "org.gnome.Nautilus.desktop" as was in 3.32.x. The
appstream ID is supposed to be stable and not change.
This partially reverts commit e3e2811b9e
Make the capitalisation of the image captions match the translatable
titles of the dialogues in the images, so that translations can be
reused.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Network access is restricted on Flatpak build env, the same with other distros running tests for packages during the build process without network access. Fixes the pipeline from failing.
This was needed for manual layout, which was still used for handling
desktop icons. Non-desktop views still have code to gracefully handle
this value.
With the refactoring from the last commit, we can finally drop this.
The org.gnome.nautilus.preferences default-sort-order key is a currently
hidden-from-UI preference that should be honored by all views, if no
custom order is specified in the current location's metadata.
However, for this to work, two enums must be kept in sync between the
code and the schemas. This has not been happening since the introduction
of the Starred files feature.
To fix this, restore the sort order according to settings, and make
starred take the place of trash-time, which is non-sensical as default
for all folders.
Forthermore, to prevent this from breaking again, add documentation to
both enums.
Fixes https://gitlab.gnome.org/GNOME/nautilus/issues/636
- imrpove the grid fit of the shapes. Primary sizes are 128, 64 and 32,
but we render at 96 in the shell in many places.
This isn't perfect and we're probably be better off sticking to 128
in the shell, but it is less fuzzy.
Adresses issue #743
It was truly unreliable and not working clearly. We have a more powerful
and simpler API with CopyURIs, so there is no point to have this one.
This commits drops the DBus API. Note that the DBus version is not
bumped, I believe this DBus API is not used by any external service
given how broken was it.
Recently we removed the ability to launch binaries and scripts in
commit 3a22ed5b8e.
A few cases appeared that we need to support, specially for enterprise
and content creators. Specifically, cases similar to https://gitlab.gnome.org/GNOME/nautilus/issues/434
This also shows that is hard to predict cases like these, as some
complex setups might be needed for specific workflows.
This commits allow to run binaries and scripts as before, and further
investigation in these cases need to be done if we ever want to tweak
the workflow of running binaries.
More discussion about improving binaries/script handling is being
proposed and discussed in https://gitlab.gnome.org/GNOME/nautilus/issues/443
This is a reworking of a long standing Ubuntu patch that publishes
the set of locations open in each Nautilus window. The motivation
for this change is that a desktop environment providing special
icons for things like removable devices and the trash can match
windows to those icons for highlighting purposes.
In the original incarnation, Unity provided these icons. In today's
world, I'm maintaining a set of patches for dash-to-dock/ubunut-dock
that provide these icons too.
The original implementation uses Xids to identify windows, but Xids
aren't a thing in Wayland so this mechanism is a dead end. Instead,
we can use the 'gtk application window object paths' which are
published over dbus by GtkApplications, including Nautilus.
Mutter already detects these, and makes them available on MetaWindows.
The original patch added the mapping property to the fileManager1
interface, and I have left that part as-is, but it's likely not to
be the right place to put it. fileManager1 is a generic interface
and a property that assumes a GTK behaviour doesn't seem right.
We could obviously add it to a new interface under org.gnome.Nautilus,
but this would be Nautilus specific - although there isn't a huge
scope for other file managers to implement this property, so perhaps
that's just fine.
dash-to-dock discussion is readable here:
https://github.com/micheleg/dash-to-dock/pull/677
For long we used to support that since the desktop was part of Nautilus.
Also, back then we didn't have a Software app where you are expected to
installs apps. Back then it was common for apps to be delivered in
a tarball, nowadays that's out of question.
Now that the desktop is long gone, launching binaries and desktop files
from within Nautilus is not as useful. Not only that, but we are moving
towards a more sandboxed system, and we should use the standard and
system wide support for launching apps based on users choices.
We also are not able to be secure enough to handle this, as we saw in
the past we allowed untrusted binaries to be launched, and therefore
we had a CVE (CVE-2017-14604) for Nautilus. We are not being audited
(afaik) and we are not in a position that we can let this issues slip.
With that altogether, this prevents launching binaries or programs from
Nautilus.
Closes: https://gitlab.gnome.org/GNOME/nautilus/issues/184
Currently, when looping over icon sizes, each icon is copied to
$MESON_BUILD_ROOT/@appid@.png, meaning that the file is overwritten on
every iteration. This commit fixes that by copying to a subdirectory
under the build root and installing from there.
Fixes https://gitlab.gnome.org/GNOME/nautilus/issues/364
NAUTILUS_PREFERENCES_FILE_THUMBNAIL_LIMIT really uses MiB as its unit,
not MB as we multiply its value by 1024*1024 (MEGA_TO_BASE_RATE) in
thumbnail_limit_changed_callback(). This commit changes
MEGA_TO_BASE_RATE and its maximum value so that it shows a number using
MB unit as advertised.
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.
flatpak-builder only exports data files that are prefixed with the
application ID. Without this, the Flatpak version does not enable shell
search functionality.
In cases where statements accidentally end with tho semicolons or where
semicolons are added needlessly (empty loop bodies), those semicolons
should be removed.
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.
Currently, Nautilus is able to save the last window position when it’s
closed. That is broken in certain cases (#197 and multi-monitor setups
in general) and therefore window placement is best left to the window
manager.
This commit does the following:
* Canonicalize the style:
* Use two-space indentations.
* Un-Autotools-ify option names.
* Don’t align arguments, simply increase indentation.
* Don’t add a space before opening parenthesis in calls.
* Remove unused variables.
* Remove unused dependencies.
* Remove config.h.meson.
* Optimize dependencies.
* Use disabler functionality for libselinux dependency, to save lines.
Instead of setting whether the search should be full text search or
not from the preference dialog, make the permanent setting from the
search popover.
https://gitlab.gnome.org/GNOME/nautilus/issues/65
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
The search text can now also match the contents of a file, besides
the file name.
This is done with the help of a Tracker query, using fts:match, which
matces both the contents of a file and the filename.
The user also has the option to choose whether to use or not the
Full Text Search. This can be done with a preference, which represents
the default option when opening a new tab/window or from the search
popover.
https://bugzilla.gnome.org/show_bug.cgi?id=775961
This hides the autostart from Ubuntu's Startup Applications
app since we don't want users to easily disable this without
understanding why it's there.
https://bugzilla.gnome.org/show_bug.cgi?id=781874
run-uncrustify.sh script uses cwd relative file names, which fails
if it is ran from the repository root or other directory.
This commit fixes the paths relative to the script.
https://bugzilla.gnome.org/show_bug.cgi?id=779408
Since it’s 2017 already, Nautilus should use a build system that doesn’t
take longer to set up the build than it takes to actually build. An
observed build time using Ninja of roughly one-fifth of what it took
Autotools is more than reason enough to add support for Meson. Along
with that, this commit adds a convenience script to generate a tarball
for releases, since we use libgd as a submodule and Meson does not
handle source distributions.
https://bugzilla.gnome.org/show_bug.cgi?id=778167
This commit removes git.mk and adds hand-written gitignore files. That
is needed to ignore build/, which is the directory of choice for Meson
builds.
https://bugzilla.gnome.org/show_bug.cgi?id=778167
After all the rework on the window slots, views, and splitting
the desktop, we are finally able to add a flow box based view for
Nautilus.
The GtkFlowBox is still not performance enough to be added as the
default view, not even as an alternative in the user preferences.
However, since the work on this is one of the biggest for Nautilus and
gtk+, the decision was to merge a prototype in order to open the
development, testing and iteration of the code in order to make it
good enough for, in a not so far away future, have it as the main view.
The work merged is not finished, and is an experiment and prototype in
more things than just the GtkFlowBox, we want to create a single shared
model with a complete MVC pattern between all the views. This will need
quite a few iterations to get it right, but once is done right, I hope
it's going to be good enough as an example to any application that wants
multiple types of views with the new widgets of gtk+.
This patch adds the GtkFlowBox view to be optionally used under a
gsetting called use-experimental-views, turned off by default.
lineup-parameters: remove unused variable (fixed upstream)
bookmark: cast away const modifier in nautilus_bookmark_compare_with()
when using GLib macros
file-operations: used correct enum in a function call
https://bugzilla.gnome.org/show_bug.cgi?id=772586
The current style of nautilus is rather poor and mixes at least 3
different code styles.
Specific issues that affect the most common contributors to Nautilus
performance are:
- tabs for multiline alignment.
- mix of tabs and spaces.
- errors on no braced one liners conditionals.
- errors on non braced case statements with variable declarations.
So I would say requirements for the style is to address the previous
issues and also be a well known style. I don't want new contributors
to see a new style completely different from C books authors.
So far, I found Allman (aka BSD) style which seems the choice of most C
books authors as far as I can see on internet, and it address the
previous mentioned issues.
Since uncrustify doesn't support the aligment of parameters we do for
multiple stars "**", we also added a script made by Sebastian Wilmet
to align those.
As a matter of practicity I'm going to convert all Nautilus style to
this one, and if the next person who contributes most on Nautilus has
a different choice, please feel free to change it to whatever makes your
performance and your contributors performance the best.
https://bugzilla.gnome.org/show_bug.cgi?id=770564
The compression operation allows multiple formats to be selected. It would be
good to store the last choice of the user in order to select it for future
operations.
https://bugzilla.gnome.org/show_bug.cgi?id=770199
Instead of using a themed icon.
This is necessary for flatpak Nautilus properly.
Patch made mostly by Mathieu Bridon and help of Patrick Griffis.
Thanks a lot!
gettext has been continuously improving, up to a point where intltool
can be deprecated in favor of it. This commit ports the project files to
use upstream gettext.
https://bugzilla.gnome.org/show_bug.cgi?id=769362
Sometimes we want to override the show-desktop-icons gsettings, as we
were doing before splitting the desktop.
Wrongly I assumed that since it's a different binary, once can simply
run it or not, but of course that was an oversimplification, and forgot
all what I needed to do in order to support all the cases for the
desktop handling.
This patch adds the missing command line options we had, --force-desktop
and --no-desktop, and also adds the --force-desktop to the classic
desktop file, since we needed to enable the classic mode.
https://bugzilla.gnome.org/show_bug.cgi?id=765159
We wanted to do this for long time. This will allow to handle the
desktop process in a different binary.
The ultimate goal is to make the desktop code completely split from
nautilus code.
This is the first and minimal step towards that goal.
In this patch we create a desktop application separated from nautilus
application, and remove the desktop handling in nautilus application.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
In icon view, add a smaller zoom level to be able for dense views,
and increase the default padding to allow the labels enough space.
Now levels are 48px, 64px, 96px and 128px for icon view, instead of
only 64px, 96px and 128px, but with the increased padding the 64px and
48px are useful.
List view also gains a bigger level, and they become 16px, 32px, 48px,
64px.
Also, adjust the label max width to be larger, but inside the icon
itself. This fixes the label not taking advantage of all the width the
icon provides, and also a few cases where icons were misaligned.
So we can select what type of view do we want for search independently
of what we normally use.
This is needed since we default to switch to list view for search, but
we would like to allow users to select a different view. However,
instead of adding a preference in the preference dialog, we can do it
more straightforward and change the setting when we are in search.
On the way, rework all the enums and views id for a saner code...
We weren't syncing the last used/ last modified setting in the search
popover when changed location, which means the query didn't get the
last used user choice.
We don't want however to listen to a gsetting key and change every
ongoing search, so instead what we do is get the setting for the
initial creation of a search, and then every user change will set
the gsetting value, but will only affect the next created searches, not
the ongoing ones.
Remote locations by default don't handle recursive search, since
it has high costs associated. We can't, however, neglect the ability
to search recursively on those folders, nor share the same setting
with common folders too.
To fix that, add a new setting called "enable-remote-recursive-search"
which will be used by the next commits to properly implement recursive
search for remote locations.
The menu item for this feature was removed in previous versions of nautilus.
A context menu item for creating links from copied files was added, but some
users prefered to create links from selected files.
Since this is demanded, implement the menu action for it and use the gsetting
added in the previous commits.
https://bugzilla.gnome.org/show_bug.cgi?id=745575
The menu item for creating links was removed in previous versions of nautilus
since it exposes a concept of the file system that is not really clear.
However, we don't have a working solution yet for the use cases that creating
links is a workaround, so we didn't remove the functionality altogether.
We were allowing link creation with a shortcut and with the middle button while
performing a drag and drop operation. However, some users would need to use a
context menu action instead of a drag and drop operation, which usually is less
convenient and prone to errors.
Since this is demanded, implement the menu action for it and add a gsetting
preference to show it in the context menu for those users who like to have it
there.
Also the new implementation uses the code that is already used for other
operations, improving the implementation compared to the previous one.
In an upcoming patch we add the UI for the preference dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=745575
So Gnome Shell is aware of it and can activate it.
Until now Gnome Shell was guessing it was able to open a new
window given the app.new-window action. However, what Gnome Shell
does in this case is just call activate of the application, which
is not the "new-window" action for nautilus, and instead only presents
the current window.
One can argue that Gnome Shell should not try to guess the available
actions to, after that, instead of using them, just activate the
application.
https://bugzilla.gnome.org/show_bug.cgi?id=756370
Since NautilusApplication is a service, we can now handle searches and
windows coming and going indipendently just fine.
This also allows us to launch a search directly from the search provider
very easily.
