File opened in recent tab now is read-only
when it is writable.
Replace nautilus_file_info_get_uri ()
with nautilus_file_info_get_activation_uri ()
fix the problem.
https://gitlab.gnome.org/GNOME/nautilus/issues/378
Originally introduced in commit e7aa2e757c,
this function used to be a lot more complex, but now it is just a
shorthand for nautilus_file_is_mime_type (file, "text/plain").
Its only use was when launching script files on activation.
Since the settings schemas no longer contain the required settings,
opening the preferences window causes an error and a call to abort().
This can be reverted if the ability to launch scripts is reintroduced.
It's often the case that an MR will be opened and call for testing or an artifact will be linked in an issue.
But by the time people review the changes or try to test it them, the provided bundle will be already gone.
In the early days of the gitlab migration the expiration was commonly set to a small interval to ease the transition and not eat up the resources of runners. This should no longer be required going forward and the expiration date can be more flexible.
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.
