Since we removed desktop support for launching and special handling in
the views, it makes sense to remove the handling in the properties
window too.
Nautilus was doing a bad job as a desktop file editor, and didn't keep
up with more relevant fields for long.
It was used for desktop files, netscape url links and other links.
However this is not really useful anymore with the desktop gone, so it
makes sense to remove it from Nautilus and have a big clean up.
This also was one of the blockers for the backend rework.
This might made sense with the desktop...althought not sure how used
was it.
For Nautilus as an app this probably doesn't make much sense, and
probably it was not very used...
Remove it so we are a step closer to remove nautilus-link handling.
We were modifying the content of the desktop file when the file was
renamed.
However we want to provide a more realistic visualization of what the
file really is since we no longer use desktop files for launching apps
on the desktop.
Remove the special handling of desktop files.
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
Split the enviroment deployment from the flatpak job.
review job depends on the flatpak job, and re-exports its
artifacts for now. Then it creates a review app, that shows
a link to the flatpak bundle.
This commit also restricts enviroment deployments for the master
branch of GNOME/nautilus.
The standalone "~" key ("asciitilde") works as a convenient shortcut
to type home-relative paths into the location entry.
However, some keyboard layouts don't have an standalone "~" key but
rather a "dead tilde" key. This makes the existing shortcut unavaliable
for some keyboard layouts.
This is surprising for most people, because they have a tilde key and
the Keyboard Shortcuts window advertises a shortcut for the tilde key.
So, add the dead tilde key as an alternative shortcut.
Note: Searching for tilded characters or the tilde character itself
is still possible by revealing the search entry is explicitly.
Fixes https://gitlab.gnome.org/GNOME/nautilus/issues/372
When comparing conflicting folders, we provide the item count for each.
However, sometimes we do not have the directory item count.
Make sure to request the item count before setting the size label.
Fixes https://gitlab.gnome.org/GNOME/nautilus/issues/269
We are showing "(null)" in the conflict dialog.
Example: https://gitlab.gnome.org/GNOME/nautilus/issues/269
Exposes the programming concept of NULL is wrong in itself, and in this
context it may lead a person to think it means the folder is empty.
Instead, get the strings with good default fallbacks.
Since the last design, the right click menu clashes with the left
click menu that is designed.
Since the pathbar is less used for interaction except for the last
button, we can simplify the UX and only use the left click.
The hierarchy of the pathbar can still be clicked with the middle
button to open in a new tab, as it's done in web browsers.
Generally actions in Nautilus were accessed through context menus or
keyboard shorcuts. However, those are not very discoverable and are
not touch friendly.
Even more, in list view it was not possible to access background actions
since there is always a selection, making Nautilus UX quite poor in that
case.
Also some actions were placed in the app menu, which didn't was not as
clear for some people given that we have most of actions in the toolbar.
In all, we came with a new design that solves the main goals of
discoverability, touch friendly and accessibility for background actions
and app actions, and now are placed in the toolbar together with an
overhaul of the looks of Nautilus path bar and search.
There is still work to do, specifically finding a design that works for
the selection actions and also to replace the current information
floating bar. The later might be just a different goal. However this
goes in the right direction.
See https://gitlab.gnome.org/GNOME/nautilus/issues/322
We were using properties and signals, but properties have already
built-in signals with notify:: for properties changes.
Use that so we have a simple and single way to notify about changes.
When the canvas container is repopulated (e.g. when using back/forward,
or pressing Esc while in a search), finish_adding_new_icons is called
leading to an accessible-children-changed event flood. We can distinguish
these unwanted notifications from desired notifications by comparing the
number of new icons to add with the size of the container's icon set.
Note that we cannot reliably identify this condition by monitoring the
is-loading property of the view: Loading officially can end while icons
are still being added. This is especially true in the case of very large
icon sets, which is the exact scenario we're trying to avoid.
libnautilus depends on both generated resource files, but the header is
only needed by the executable and there is no dependency on it to enable
build parallelism, since both targets can be built independent of each
other before linking.
Fixes https://gitlab.gnome.org/GNOME/nautilus/issues/380
Accessible name-changed events should not be emitted during the
initial load of the icon container. They should only be emitted when
a user-triggered action such as renaming the file causes the change.
This event is being emitted when the editable_text property is being
set. During the initial load the value is null, so check for that
condition and only emit the event when the original value is non-null.
