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.
